Age | Commit message (Collapse) | Author | Files | Lines |
|
Fixes silly bug causing slimes failing to split in some cases.
Reported-by: HoraK-FDF
|
|
Extras for spawns on mob kill - actual **slime splitting** fun is **here**.
The following extra spawns are in effect (compared to already merged):
Mob -> to what it decays
GreenSuperSlime -> AngryGreenSlime (same as GreenSlimeMother split)
YellowSuperSlime -> YellowSlime
RedSuperSlime -> RedSlime
BlueSuperSlime -> BlueSlime (fewer than former as they're powerful)
|
|
2) If only 1 mob requested to spawn, spawn on exact spot.
Rationale: if its just 1 mob, it likely important, yet areaspawn can
spawn fewer mobs than requested if e.g. some collisions are in area.
Idea is that if mob can be killed on X,Y its certainly not collision
so single important mob better off using use this location.
|
|
1) Add check Luvia witch is not on Illia map (052-2), It its Illia, omit spawns for now to be on safe side.
2) Fix of silly typo causing bug in witch spawns
(in fact they were not working at all, parameters sanity check did its part and aborted call).
|
|
issues in Sages quest
|
|
|
|
|
|
Useful to sub-split slimes and do similar extra tricks.
Relies on https://git.themanaworld.org/legacy/tmwa/-/merge_requests/292
Mentioned server change provides X/Y of mob kill so e.g. slime "split"
can look reasonable - spawning new slimes where killed mob been.
This is preliminary version, so far it introduces following spawns:
Mob Killed -> What appears
1) Sea Slime Mother -> angry sea slimes on kill.
2) Green Slime Mother -> angry green slimes on kill.
3) Blue Slime -> few SlimeBlast (same as it spawns)
4) Tormenta -> Void Bats + Demonic Spirits + undead witch.
5) Luvia -> Void Bats + Demonic Spirits
(slightly fewer so Illia players arent instakilled hopefully)
TODO: Add few BIG slimes decaying into existent "normal" ones.
E.g. BIG green slime -> bunch of angry green slimes.
or BIG Sea Slime -> bunch of angry sea slimes.
(this needs GFX of big slime and turning it into mob)
|
|
1) Fix check so sprite ID 325 (black ring) could be used. It was just
some silly typo that prevented it. Corrected.
2) Attempt to take on visual bug where SC_SLOWMOVE effect icon
could linger even after teleportation sequence completed.
(harmless visual glitch - no real slowdown in effect)
|
|
killed eventer playing powerfull boss.
It implemented by setting PC_BOSS_REWARD character variable
via @setvar on eventer. If this variable set on killed character,
its value = amount of boss points to award to PK killer.
|
|
1) Clean up a lot of debug messages.
2) Fix few typos and so on.
3) remove "if (debug)" from access check to be on safe side
|
|
Co-authored-by: HoraK-FDF <horak-fdf@web.de>
|
|
Its attempt to get best of @addwarp, GM Island teleport and Illia
teleports - making visually OKish teleports with desirable properties.
On user visible side this allows to open nice looking teleports into
arbitrary destinations, that do FX effect upon player stepping on them.
But its more.
* New teleports can be instatiated as needed, running side by side.
* Teleports can have finite lifetime, disappearing themself.
* Teleports can be removed, leaving no side effects.
* No leftovers or side effects after teleport removed.
* There's way to "globally" track all "tracked" teleports.
* Up to 100 "tracked" teleports can coexist - and this list can
be displayed or managed.
* Flexible condition check based on cookie. If some gate got cookie set
then it only lets players with matching variable to pass.
* Aspects like timeout, FX and their timing, etc can be customized.
(for safety reasons @teleportadd allows only few NPC sprites and few params)
* Teleports meant to be registered in TeleportManager. However, its
possible to create "unmanaged" teleports (e.g. for spells).
* In future it can allow custom hooks/checks on teleporters (planned)
* Attempts to reasonably validate input and refuses to do apparently
invalid things like landing on collisions or bad map/coordinates.
* Builtin help.
Overall it meant to
* Play events with better FX effects on arbitrary maps, including
e.g. chaining inaccessible ones.
* Keep track of all open "managed" gateways - being able to manage
all established wormholes.
* Reusable component (function) doing teleport setup - and overall quite
configurable thing via NPC vars, reusable from e.g. spells or
various quests. So quest or spell can open e.g. transient reasonably
looking self-destroying teleport easily, etc (these are not
tracked and would not appear in @teleportlist but can in principle
be force-closed via @teleportdel if caller knows NPC ID)
To get started: type @teleport or @teleporthelp. @teleportadd will also do.
|
|
I probably missed some. I may have a few errors, but I sure found a lot of npcs that are magical and ready for detection with #miteyo. TY Hello=) for the IS_MAGIC code.
Reviewed-by: Hello TMW <hello@themanaworld.org>
|
|
This reverts commit bab8a25d6d3a2a5f5173654c95d057c65a3fa4f6.
Reason: its confusing if PC variable name looks same like server's param name.
|
|
|
|
|
|
Differences vs previous version:
* Allows to set "arbitrary" weight limits (within i32).
* Does NOT makes hardcoded assumptions on nick or weight.
* Reusable for >1 trade bot if desired.
* Acts a bit like ACL, most of it done by server itself.
* Still oneliner :)
Usage: @setvar WEIGHT_LIMIT 0 10000000 ManaMarket
Since its per-character variable, user must be online.
|
|
Naive approach using stats failed. But even more direct way works.
This sets MaxWeight on MM login to 10 000 000 aka 10 000 kg aka 10 tons.
I think 10 tons "should be enough for everyone". I've actually tested it
works by heavily loading ManaMarket replica on local server with itens.
|
|
|
|
|
|
killed in rain by own lightning.
Problem technically can be described like this:
1) Caster retains all spell charges upon death for lightnings.
2) It wouldn't be problem itself, but it would invoke OnAttack handler!
3) If caster dies in rain by own lightning, nothing clears "in rain" flag.
4) When they respawn and try to attack, OnAttack kicks in.
5) Since nothing has cleaned "in rain" flag, its still set.
6) At this point caster dies by own lightning again.
7) Worse, on respawn sequence would repeat itself.
This happens regardless of rain and is very unexpected edge case.
Workaround: caster can use #dicharge spell after respawn but its unobvious.
|
|
|
|
|
|
|
|
When a character checks in with a daily point NPC, the bonus daily
points (from boss fights) gets moved into the regular bonus variable. By
my understanding, when this regular bonus variable exceeds the
character's level, the character stops gaining regular daily points.
As you can see, when DailyQuestPoints exceeeds character lvl (97), the
player no longer gets any (DailyQuestTime marks the last time the base
points were added):
Initial state:
[16:53:57] variable DailyQuestBonus[0] == `0` for player AnotherOne.
[16:54:03] variable DailyQuestPoints[0] == `2` for player AnotherOne.
Character receives bonus:
[16:55:15] variable DailyQuestBonus[0] = `150` for player AnotherOne.
Character talks to DPQuest NPC without items, bonus is moved:
[16:55:38] variable DailyQuestBonus[0] == `0` for player AnotherOne.
[16:55:47] variable DailyQuestPoints[0] == `152` for player AnotherOne.
Reset login time in order to get new daily points:
[16:56:06] variable DailyQuestTime[0] = `0` for player AnotherOne.
talk to NPC again:
[16:56:16] variable DailyQuestBonus[0] == `0` for player AnotherOne.
[16:56:21] variable DailyQuestPoints[0] == `152` for player AnotherOne.
|
|
|
|
|
|
This brings back the ability to set stats during character creation. It will need to be tested first to ensure that new characters do not gain an additional 30 stat points and to make sure that current characters gain 3 more. Also, I'll need to make one more MR, probably, when I find out where character points on character creation are set. Will need to change from 48 to 54 in order to achieve 30 points, I think, though I may need to change 48 to 0 if this is set after login. Simple things are rarely simple in practice. GAH!
****
Approved-by: Led Mitz <smoothshifter@tuta.io>
Reviewed-by: Led Mitz <smoothshifter@tuta.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This allows @HoraK to implement !623 correctly, respecting "take all" option
|
|
|
|
|
|
|
|
|
|
This allows TMW Legacy to make near full use of the Mirror Lake Protocol.
|
|
MLP takes 3 variables, Vault takes 3 variables, TMW takes 3 variables for 9 total.
Each world you connect to takes 3 more variables out of a total of 16 accreg2.
Meaning, you can connect to two worlds: Moubootaur Legends and rEvolt.
If a fourth world is ever added, TMWA/MLP will have an attack and die silently.
|
|
|
|
|
|
|