Ender

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.