| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Also remove {install,version}.hpp from source control, so they're actually
generated.
There may be a better way to handle this, but I'll just leave a note as a
TODO for now.
|
|
Use execute_process instead of add_custom_target to make sure the
generated files are found on the first configure run.
Set CMAKE_CONFIGURE_DEPENDS so that touching the script generating files
will automatically trigger a re-configre, which will re-run the make
process.
|
|
|
|
The values of defines in these files should be the same as those set
from version.mk / Makefile.in.
|
|
|
|
|
|
attoconf is a bespoke build system that has seen little maintenance, and the
overwhelming majority of build logic happens inside real.mk, here Makefile.in.
While attoconf and real.mk provide a lot of very nice functionality, it
doesn't integrate so well with IDEs, and is very intimidating for prospective
developers. Providing a full cmake based approach solves both of these
problems, and there isn't anything so complicated in tmwa that it needs its
own build system.
WIP: This represents a messy dump of CMakeLists.txt in the last state I left
it. It has been shared to make collaboration easier, but should by no means be
considered anything more than exploratory at this point.
|
|
.mk is more widely understood than .make, for IDE usage.
|
|
C++0x was released as C++11 nearly a decade and a half ago.
My version of cmake doesn't recognize it in CMAKE_CXX_STANDARD, which
makes before/after comparison difficult.
|
|
Extremely minimal, not touching any __future__ imports or such.
For serious use, see specing's WIP PR at:
https://git.themanaworld.org/legacy/tmwa/-/merge_requests/256
|
|
This configuration variable changed from signed to unsigned with the
move to Python-generated config file parsing in
e1418f378c66343a35db3791cbf0d54a4be3fbd3 and
c482e420bcf447073ffe3ff8a106a0561e0baadd.
Changing it back to signed because it is compared to a signed integer
returned from count_users. Also, having it as signed integer allows
setting it to a negative value to refuse any user connection.
|
|
This commit lands fix for infamous AFK-kill summons exploit.
Its what essentially caused summoner spells in cities to be disabled.
This is not free lunch: it comes at expense of little fun where
mob would bite bad master hitting it. But its been minor fun or
cosmetics while spells restriction in cities and so on is annoying
setback for mages.
So if choosing between evil and even more evil, guess...
Technically, server's bug is: it too eager to reattach some things to
wrong RID or something like this. Its what causes aggroed mob to
lock on really wrong random targets and AFK-kill them.
|
|
|
|
|
|
efficient.
Credit to @Hello for figuring this out :)
|
|
|
|
Nice consistency there, past!Freeyorp.
|
|
`npc_scriptcont` now consistently returns 1 on failure, though in practice,
this return value was always ignored.
|
|
055-1 _nodes.txt will call `destroy;` from within OnInit, that is during an
iteration of the global `ev_db`. Previously, concurrent modification
invalidated this iteration, resulting in a crash.
This still nullifes `oid`, dequeues all timers, and effectively calls
`builtin_end`.
`npc_data::deletion_pending` is extended to include a third state.
In addition to no deletion happening, and indicating when `npc_free` is
currently on the stack, it now also tracks whether the NPC is about to be
deleted by a timer.
This means that an NPC which is about to be deleted is still blocked from
triggering new events, much like an NPC actively being deleted would.
Starting or continuing an NPC dialog with an NPC that does not, or is about to
no longer exist, is now also blocked.
|
|
|
|
This is some rather impressive type safety, albeit safety that has evidently
desensitized people to warnings for rather serious problems.
|
|
PR !270 is an ongoing investigation into outstanding compiler warnings.
One such warning is `warning: format '%s' expects a matching 'char*' argument`
from `script_nullpo_end(nd, STRPRINTF("no such npc: '%s'"_fmt, name));` in
`src/map/script-fun.cpp`. No such warning is emitted from a similar line in
`src/map/atcommand.cpp`: `AString output = STRPRINTF("Jump to %s"_fmt, npc);`.
`script_nullpo_end` is a macro, rather than a function. `error` is passed in
verbatim by the preprocessor. The macro definition of `script_nullpo_end`
includes lines such as the following:
```cpp
PRINTF("script:%s: " #error " @ %s\n"_fmt, BUILTIN_NAME(), nullpo_nd->name);
```
`#<variable>` instructs the preprocessor to transform `<variable>` into a
literal string. In this case, the string literal:
```cpp
"STRPRINTF(\"no such npc: '%s'\"_fmt, name)"
```
So the entire line partly resolves to something like:
```cpp
printf("script:%s: STRPRINTF(\"no such npc: '%s'\"_fmt, name) @ %s\n"_fmt, BUILTIN_NAME(), nullpo_nd->name);
```
Once the compiler sees this, it throws out the warning seen here, because
printf is seeing three placeholders in the formatter, but is only given two
value arguments.
Checking with `gcc -E`, the full expansion is as follows:
```cpp
if (nullpo_chk("script-fun.cpp", 4885, __PRETTY_FUNCTION__, nd)) { if (st->oid) { dumb_ptr<npc_data> nullpo_nd = map_id_is_npc(st->oid); if (nullpo_nd && nullpo_nd->name) { ({ struct format_impl { constexpr static FormatString print_format() __asm__("_print_format") { return "script:%s: " "STRPRINTF(\"no such npc: '%s'\"_fmt, npc)" " @ %s\n"_fmt; } }; cxxstdio::PrintFormatter<format_impl>::print((
# 4885 "script-fun.cpp" 3 4
stdout
# 4885 "script-fun.cpp"
), (builtin_functions[st->stack->stack_datav[st->start].get_if<ScriptDataFuncRef>()->numi].name), nullpo_nd->name); }); } else if (nullpo_nd) { ({ struct format_impl { constexpr static FormatString print_format() __asm__("_print_format") { return "script:%s: " "STRPRINTF(\"no such npc: '%s'\"_fmt, npc)" " (unnamed npc)\n"_fmt; } }; cxxstdio::PrintFormatter<format_impl>::print((
# 4885 "script-fun.cpp" 3 4
stdout
# 4885 "script-fun.cpp"
), (builtin_functions[st->stack->stack_datav[st->start].get_if<ScriptDataFuncRef>()->numi].name)); }); } else { ({ struct format_impl { constexpr static FormatString print_format() __asm__("_print_format") { return "script:%s: " "STRPRINTF(\"no such npc: '%s'\"_fmt, npc)" " (no npc)\n"_fmt; } }; cxxstdio::PrintFormatter<format_impl>::print((
# 4885 "script-fun.cpp" 3 4
stdout
# 4885 "script-fun.cpp"
), (builtin_functions[st->stack->stack_datav[st->start].get_if<ScriptDataFuncRef>()->numi].name)); }); } } else { ({ struct format_impl { constexpr static FormatString print_format() __asm__("_print_format") { return "script:%s: " "STRPRINTF(\"no such npc: '%s'\"_fmt, npc)" " (no npc)\n"_fmt; } }; cxxstdio::PrintFormatter<format_impl>::print((
# 4885 "script-fun.cpp" 3 4
stdout
# 4885 "script-fun.cpp"
), (builtin_functions[st->stack->stack_datav[st->start].get_if<ScriptDataFuncRef>()->numi].name)); }); } st->state = ScriptEndState::END; return; };
```
Note the string literal: `"STRPRINTF(\"no such npc: '%s'\"_fmt, npc)"`.
`script_nullpo_end` currently can't take as its argument for `error` any
expression which, when stringified, contains something which `printf` will
interpret as its formatter expecting another argument.
This appears to have been broken since it was first introduced in
https://git.themanaworld.org/legacy/tmwa/-/commit/594eafd4f231a897cbefd
since the first revision implicitly had these requirements, and also
introduced usage which didn't meet them.
This rewrites each PRINTF line in `script_nullpo_end` from the template
```cpp
PRINTF("script:%s: " #error " @ %s\n"_fmt, BUILTIN_NAME(), nullpo_nd->name);
```
to something like
```cpp
PRINTF("script:%s: %s @ %s\n"_fmt, BUILTIN_NAME(), error, nullpo_nd->name);
```
This means that instead of an expression being stringified, error is
interpreted as an expression that resolves (or decays) to a string.
This seems consistent with all current usage of `script_nullpo_end`.
|
|
|
|
|
|
Squash with: remove empty lines
|
|
|
|
C++11 was a really long time ago, huh?
|
|
|
|
|
|
In serverdata@c3b7fe59a, `magic-knuckles` made use of temporary copies of the
spell NPC via `puppet`/`destroy` to provide additional functionality. This
implementation was correct with respect to tmwa behaviour as documented.
However, `puppet` and `destroy` doesn't quite return the server to a clean
prior state. In `builtin_puppet`, events with the fresh new copy of NPC are
registered into the global `ev_db` map to track named events, such as
`OnDischarge`, which might be triggered later. However, these registrations
are not reversed with `destroy`, leaving `ev_db` to retain references to now
invalid and destroyed NPCs.
serverdata@c3b7fe59a revealed this oversight through an intersection of rare
conditions:
- An NPC that is routinely cloned and destroyed
- Having a variety of events
- Including one that can be triggered during a search for the event over ALL
NPCs when `#discharge` is cast.
To reproduce, compile with `-fsanitize=address -fsanitize=undefined` to more
reliably catch use of invalid memory, cast `magic-knuckles`, log out the
character which cast `magic-knuckles` to destroy the NPC, log back in, then
cast `#discharge`. The server will then crash.
Special thanks to SystemError for testing out this theory. Currently lacking
a test environment of my own, this would not have been possible without his
patience and diligence.
|
|
Blame Ledmitz (:
|
|
|
|
Preserve @exprate as a shortcut for both & because scripts in serverdata call it
|
|
|
|
+Pass artifacts (well, the whole repo) to test stage
+YAML syntax error. Since I saw a glimpse of the repo being reinitialised
two tries ago, perhaps it saves everything tracked and just adding
untracked files should be enough.
|
|
Function "_Z13do_breakpointIN4tmwa3map11script_dataEEvRKT_PKc" not defined in "/builds/specing/tmwa/src/debug-debug/map-script-persist.cpp".
Breakpoint 1
(/builds/specing/tmwa/src/debug-debug/map-script-persist.cpp:'_Z13do_breakpointIN4tmwa3map11script_dataEEvRKT_PKc') pending.
void do_breakpoint<tmwa::map::script_data>(tmwa::map::script_data const&, char const*);
Thanks to ssbssa@#gdb for pointing this out.
|
|
It's no longer maintained by o11c since many years now, so an update was
long due.
Also updated some outdated links.
Finally, who can say for sure that The Mana World will never run on
Manaserv?
|
|
requires C++14.
|
|
Note how gcc uses /usr/include/gtest (default search path) as the -I for GTEST_DIR is not on the gcc command line:
System-wide gtest is 1.14 and requires C++14 while provided one is 1.8.1.
GTEST_DIR="$PWD/deps/googletest/googletest" ./configure --user
make[1]: Leaving directory '/data/users/tmwa/proj/tmw/classic/tmwa'
find: ‘doc-gen/’: No such file or directory
g++ -std=c++0x -I . -I ./include -DGENERATING_DEPENDENCIES -O2 -g
-fstack-protector -fno-strict-aliasing -fvisibility=hidden
-fvisibility=hidden -MG -MM \
-MT 'ast/item_test := ' \
-MF obj/ast/item_test.d src/ast/item_test.cpp
In file included from /usr/include/gtest/gtest-message.h:57,
from /usr/include/gtest/gtest-assertion-result.h:46,
from /usr/include/gtest/gtest.h:64,
from src/ast/item_test.cpp:21:
/usr/include/gtest/internal/gtest-port.h:270:2: error: #error C++
versions less than C++14 are not supported.
270 | #error C++ versions less than C++14 are not supported.
| ^~~~~
Makefile:331: obj/ast/item_test.d: No such file or directory
|
|
* Removed the <details> tag used to hide the main contents.
* Removed deprecation notice, since we're still running this server
and will need to maintain it until it has been replaced.
* Deleted the section about tmwa-monitor, since the tool is not just
deprecated but actually was deleted in
53a91a3fbf0929a99abcdfea23126f978c3ce71a.
This partly reverts da50c517000391c83305ff704e3059c900f28d5b.
|
|
See "Item Mode" commit from Apr 3 2023
|
|
Enable GitLab CI
See merge request legacy/tmwa!259
|
|
tools/protocol.py: Added generation of client code
See merge request legacy/tmwa!258
|
|
This helps with keeping the protocol in the Mana client up to date.
****
|
|
+Add meway's Ubuntu
+Add python -> python2 symlink
+Separate python/python2 into INSTALL_PACKAGES
|
|
Fix bug whereby stat updates were not sent to client after equipping +1 stat...
See merge request legacy/tmwa!257
|
|
pt item when base stat is 1.
What is funnier is that it sent updates for all other 5 (unchanged
stats). Example, amethyst ring +1 dex:
Sending update for stat 0: saved: 0+1, new: 0+0 (str?)
Sending update for stat 1: saved: 0+1, new: 0+0 (agi?)
Sending update for stat 2: saved: 0+1, new: 0+0 (vit?)
Sending update for stat 3: saved: 0+1, new: 0+0 (int?)
Sending update for stat 5: saved: 0+1, new: 0+0 (luk?)
|
|
|
|
activity checks and status cleanup
See merge request legacy/tmwa!252
|
|
|
