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

Nope. Lame's grind on this server goes up to +35 which wouldn't fit the 50 ATP for the max roll ATP. You can unseal without grinding it. (Probably because the use option for Lame is hardcoded and Sega just didn't implement a grind a requirement.) But you could always setup your own server using the same base client and remove the grind from Lame d'Argent to see that the resulting Excal gives you the same damage rolls over a sufficiently large set of data points. You could also modify the stats of Excalibur in the ItemPMT to have max ATP set to 900, 1000, 1500, 5000, whatever you want, and verify the damage rolls have changed accordingly. Or you could nerf the Lame's stats to min and max ATP 1 to show that the weapon stats are independent of each other.

I don't think there is any error with that data listing. It's a dump of the data for the item from the ItemPMT, and in the ItemPMT there are two fields that are definitely the weapon's ATP min and ATP max for attacks. How people read/interpret the fields can be erroneous, but there's no error in that displayed data.

For some reason, the "Settings Editor" addon is failing to load the font for you. It should fallback to the default font but I don't know if the latest plugin release has this. The code was pulled into the plugin but there hasn't been a release of it with that fix. Anyway, you can close your game and remove the "Settings Editor" folder insider your UltimaPSO\addons folder. That should restore the default ImGui font for you. Is there anything particular about your Windows setup? The default fonts for the Settings Editor should work just fine and I've only ever seen cases of it not working on this forum. There has to be some reason for it failing to load the font for you or rendering the font incorrectly. Are you using some strange DPI setting in Windows?

There's a choice for server in the Item Reader's configuration window. Select Ultima and that should fix it.

The 'dark chao' mag on the left is a reskinned regular Chao mag. The mag on the right is a reskinned Naga except two of them, similar to Twin Sato. I know they have some sonic theme for an event and a 'new enemy' using a Robotnik model, but I was under the impression those were model replacements and not new models added into the game. Could be wrong.

Calling it the Viridia table is probably a misnomer. It's just the first table in the cmode section of the itemPT, which happens to be the same slot used by 'Viridia' for the normal mode tables. This CM table is the one and only table for CM. The other tables are mostly copies of the normal mode tables, so using those would give you stuff like ABeast weapons dropping in Forest or Native in Ruins, for example. The CM table is not identical to any table used for normal mode. The shot chance in this CM table is 6%, whereas Viridia in normal mode is 11%. For reference, this CM table is 13% Sabers/Handguns/Canes, 7% Swords/Daggers/Partisans/Rifles/Mechguns/Rods/Wands, and 6% Slicers/Shots.

You still DC on Ephinea after some number of detected desync issues, or earlier if the desync leads to something horribly wrong from the server's perspective. Section IDs shouldn't matter for CM. There's only one table defined for CM in the itempt and it's just the first ID table, which happens to be Viridia. From Soly's post, sounds like Ultima is using that table correctly.

There's nothing in the log because the fonts are changed outside of the lua context, so it can't really throw a stack trace into the log, but there's probably a way to add something into the log regardless. The addon tells the plugin to load a font with some settings, the plugin does it between the next frames for the addons. There definitely are some cases to fix in the error handling and I'll try to fix that this week, as well as add something to tell you that it failed to load a font and at least an error code. With those fixes, at least it'll revert to the old default bitmap font that's embedded in the plugin. I'll probably also add a way to disable the settings editor from the configuration menu as well.

Weird. I haven't seen this with the Settings Editor changes. Did you also install the addons/fonts folder included from soly's updated plugin dll? Assuming you did install the fonts folder correctly, one thing you can try is going into addons/Settings Editor folder and renaming the options.lua. Then try reloading addons or relaunching pso. It should generate default options which load the old font. EDIT: Someone else just posted the same issue on discord for another server. For them, they were able to workaround it by removing the Settings Editor addon. I'll look into why it's breaking. EDIT2: Are you running this in Windows or in a VM/WINE? Just trying to narrow down what's causing this issue.