Ender

I think you might be underestimating the amount of effort to implement this.

If you're asking whether it's a bug with Serene Swan, then the answer is no. If you're asking whether it's a bug or oversight in the game? Depends... Here's why this happens. Most projectile weapons in this game fire a bullet in one of two cases: either straight (no target) or to a targeted enemy. The target case is what's important here. The game calculates the distance between source and target points and divides it by the bullet's velocity to calculate the number of frames for it to live. Once it reaches that number of frames, the bullet is destroyed by the game. The problem is that hard attacks can push back enemies, causing the bullet to be destroyed at the target's old position (or more specifically, at some point inside the target's hitbox when it was fired). If the enemy was pushed back, then the bullet is destroyed by the game before it reaches the target's current location. So is this a bug? I would say no because it's quite similar to manual evasion. The main difference is the game provides visual feedback for manual evasion, although it looks the same as an accuracy failure (not very helpful from Sega but oh well). A number of weapons fire a different type of projectile often called a 'launcher' projectile (Photon Launcher, Guilty Light, Rambling May, Rianov 5, Frozen Shooter special, Snow Queen all attacks, many 'Card' type weapons, Ultima Bringer's special attack, and others). These projectiles mostly don't have this problem because the projectile is destroyed when it collides with the maximum number of targets or reaches its maximum distance. Although in classic Sega fashion, a set of these launcher projectiles such as the ES CARDS weapons have a different bug which causes the game to destroy them one frame early, so they fail to hit targets at max range sometimes.

There isn't an opcode for this. You need to implement it using a list, probably for a single digit at a time.

No, that's expected. The client has a list that has room for 1448 total for the quest. It tracks the total amount used when adding monsters. Monsters are added on a floor by floor basis. The .dat file in a quest is actually concatenated tables, where each table specifies which floor it's for. If the monsters for a floor won't fit, they won't be added in client memory, but the game will still continue parsing the .dat and try to load them (might be mistaken about it continuing to load things after, but honestly this is such unexpected behavior and your server needs to know about these limits or else monster IDs will be out of sync between client and server). If you have 3 NPCs on Pioneer 2 and then 1446 NPCs/Monsters in Forest 1, Pioneer 2 will load its NPCs but Forest 1 will not. "Initialization monsters" => the things you see in the NPC/Monsters list in Qedit. NPCs and monsters are the same in quest files. Nothing to do with waves. A floor is just a single map. Mop-up Operation #1 uses floors 0 and 1, designated as Pioneer 2 and Forest 1 respectively. Towards the Future uses floors 0, 2, 5, 7, 10, 11, 12, 13, 14 (and also 8 for the Striker of Chao conversion). These are designated as their standard maps. Areas/maps are imo interchangeable but I know some players say things like "Forest area" to mean "Forest 1 and Forest 2." A quest can have multiple floors using the same or different areas. Challenge Stage 9 in Episode 1 uses floors 1 to 5, each designated as Ruins 3 area, with different map variations, and also uses floor 14 for Falz.

Maximum number of initialization enemies in a quest is 0x5a8 = 1448. The way this works is a bit odd. If a single floor will go beyond the limit, the game will ignore all enemies for that floor and go on to the next floor. This is the number of 'initialization monsters' which matches the list you see in Qedit, meaning that a "Canune" costs only 1 even though it will create multiple entities at runtime. Maximum number of objects in a quest is 0xba0 = 2976. Similar oddity as the max number of enemies. Map events are harder to put a limit on. The game allocates a 32KB chunk of memory and uses it for map events and their clear events. The map event table for the floor is copied in directly, including the header. There are also tables 4 and 5 which are used in ep1 challenge only on a vanilla client but leaving them out of this post. Those are limits just for loading the .dat into memory. There are also runtime limits. There's a limit of 652 entities active at any time, where entities includes basically any object with with collision or interaction. This limit is probably supposed to be a little lower--652 is just the number of elements that can fit in the data area before it overwrites the next symbol and guarantees a crash. This limit includes enemies, players, items on the ground, and even some objects in the map's geometry like the little plants in Subterranean Desert 2. If you run War of Limits 4 and every enemy drops an item, and if the host is on Pioneer 2 so that they don't perform the 50 item limit cleanup, then you'll 100% crash a few rooms before the end. The game 'remembers' information about 0xb50 = 2896 enemies/npcs and 0xba0 = 2976 objects. This information includes clones for enemies, so a quest near the 1448 limit could hit this with the clones from bosses and other enemies factored in. There are also other issues with quests that have this many monsters per floor. Photon Blasts can crash with too many targets in a chain (never investigated the details). The game will remember only 192 item boxes on a floor which can lead to disconnects if other players drop & pickup items when your client's 'stored item list' for that floor is already full. Certain techniques will hit their max number of entities, which isn't really a huge problem but it allows things like Gifoie to hit enemies on every single frame and instantly kill most things.

It's probably a server bug. Public Teth doesn't parse the quest file to know the maps and assumes the area by floor number. The assumption being floors 16 and 17 in Episode 2 (used in PW4) are Tower. Probably the same case here (which is also why MAS2's nonrare weapons and tech disk drops look like they're Temple tier drops). This quest has three Tower areas and it looks like two of those areas are using floor numbers 8 and 9. So in those two areas, Del Lillies are treated as Ob Lillies (and can be rolled rare on the server). And Epsilons are probably treated as Sinow Zoa/Zele in those areas (depending on their initialization param in the quest file).

Oroti special does a tiny bit more than hard damage. Raikiri special does a tiny bit less than normal damage. Both specials are affected by weapon attributes. EDIT: I should clarify that I looked at this on a vanilla client. It's possible this was changed here so you should test for yourself

Look at the post above yours 😉 Also if they can figure out why this happens for them, that would be GREAT to know so that I can fix it in the lua plugin. Are they using a weird Windows DPI setting? Some graphical wrapper renderer thing like dgVoodoo? Launching the game through some other program?

Looks like it's positive for PB Full and Boss. I did some testing on the test server to verify and looks like it's correct. A bit surprising /shrug You could test the boss boost yourself on the test server by warping in and out of some boss arenas. Make sure you end your current invuln before you warp again. So something like this for Episode 1: /warp 14, unequip and re-equip mag while still in Falz arena to clear invuln state, /warp 0 back to P2, and repeat. "RNG" and everything, but should be a decent representation over enough tests.

For the most part, weapons that shoot normal photon bullets use their group index to know which photon bullet from data.gsl/gun_bullet.xvm to load. Main exceptions for photon bullets being the TypeM weapons which map to color 1 for blue, because there's no white photon bullet. This is hardcoded into the client. And there are many weapons that have special particle bullet functions to create some other particle. Also built into the client. I've never actually modified these before, but this should work... FS uses particle 0x55 and SQ uses particle 0x1f5 for their bullets (these are hardcoded values in the client). Two ways to modify these. There's some old particle editor by Lee somewhere. You can open particleentry.dat (from data.gsl if you don't have one) and go to those entries. Modify and save the file into your data folder, then relaunch the client. Alternatively you could modify the textures they use. In the particle editor, you'd see that particle 0x55 uses texture ID 0xB723D and particle 0x1f5 uses texture ID 0xAB02C. You can find those in effect_nt.xvm and change that. But this affects all particles that use this texture, which you probably don't want.

Bug in the quest script.

The quest has an off by one error when it rolls the random number for the rewards. Twelve rewards and it's rolling a number in range [0, 11) which means 0, 1, .., 9, 10 are possible values. You need to roll an 11 there to get SoF.

The item display stuff in Item Reader had a bunch of updates over the past year+. The COLOR_DFLT, COLOR_ARMOR, etc variables are just color values, usually specified in AARRGGBB hex format like 0xFF00FF00 for full alpha green (0xFF = 255 Alpha, 0x00 = 0 Red, 0xFF = 255 Green, 0x00 = 0 Blue). lib_items_cfg module is the stuff in solylib/items/items_configuration.lua so you could modify some values there if you want to tweak some of those colors, or you could just change some of the variables in items_list.lua. But if you're going to pick one version of a file, like items_list.lua, and mix it with a much older file version, you'll probably get some undesirable results in your addons (non-zero attributes disappearing from items is a really common issue if you do this). So it's probably wise to update all of Soly's addons that you're using if you're going to do this, and of course backup your existing stuff.

The quest crashing seems to be caused by Ultima's custom Meriltas skin and also affects Seaside Night in other quests. If you bring that bm_ene_re8_merill_lia.bml file to another server or your own public Teth setup, then you'll start seeing the same crash. Debugging it on my own Teth client shows it's crashing while decompressing one of the xvm files inside that bml. So you could remove that file to avoid crashing in the quest, or maybe play on low enemy detail because the low quality version might be OK (tested only a dozen times). Or wait until a fixed BML is available.

69