Pretty much at this point I thought I was missing only the ++/-- on slots, which isn't defined in the PT file (the rates that it is +/++/-/--/normal I mean). Although I have not seen the BoxDrop or the ArmorSet you posted as part of your PT struct. The PT viewer was based around how Teth handled the PT file in the first place, and as I started correcting more and more stuff I consolidated/expanded many of the tabs. By changing parts of the PT file for an emulated copy of PSO+ helped me to figure out what was correct and what was wrong. And it still is missing a few things, ie I haven't gotten around to rewriting the armor tab as well as moving everything in the grinds tab to the attributes tab, since the grind pattern is determined by what is defined under the attributes tab and there's nothing you can really "change" about what grind pattern a weapon would utilize for a given area unless you were to change the min rank/upgrade every # of floors.

This explains why you incorrectly boosted dar rates now. I almost did the same myself when tool drops where too few and far between, then I found the box drop % for item types which made it all clear.

Enemies drops are pretty scarce, their dar rates are really low, but boxes on the other hand are boosted up.
Might want to include it.

I assume you understand those delphi arrays
It reads like this for general box drops random not fixed when set as fixed type:

weapon
Armor
Shield
Unit
Tool
Meseta
Nothing

example for forest 1:

weapon 2%
Armor 1%
Shield 1%
Unit 4%
Tool 62%
Meseta 0%
Nothing 30%

obviously 10 sets of this 1 for each floor.

you should know how armor data works I remember explain it to choko once, 1 byte ofset by floor to give 5 values easier to show then explain though lol.

Additonally there is no value for % based on ++/--
instead there is a single max star value, if you pay attention you will see that the star value of the unit changes according to the +/- of the unit therefor change the floor it can appear on, i remember speculating it was linked to the armor set values and %'s, but in practice when tested it was just a flat random rate of all available units to that star value on said floor. I once tested this by putting 100 boxes in 1c1 setting the unit box rate to 100% (all in 1 room btw) and just breaking them over and over while changing the star rate.

Teth's pt stuff was based on alot of my early research implemented by soda, before i went though the data comprehensibly, problem was, once i knew how everything worked soda couldn't be bothered fixing them.

Ahh, the box drop % actually makes much more sense. I guess since I (incorrectly) assumed that all of the necessary data had been read from the PT file for each difficulty/ID, that the way Sodaboy had box drops was correct, even though it was rather silly. But your way makes much more sense, and would explain the DAR being low for enemies in Cmode, as you stated, as well as boxes needing to have a rate at which they wouldn't drop an item. The armor data I do understand as well. Guess it's just a matter of implementing all of those things into the source when I get a chance.

For tool drops from enemies, for normal mode it's a flat 33% rate after the DAR check is passed, with the other two options being the enemy drop type and then a meseta drop. What did you change that to for cmode enemies, and how did you determine that? I know at one point you said it was a greatly reduced rate from enemies...

it is 33%, tbh it's a pretty arbitrary guess on my part based on observations when i set dar to 100% and just killed enemies (I did a lot of this using psox ), i know not exactly scientific but it worked, the reduction for tools I mentioned was based on the fact that 33% of 10% drop anything is pretty dam low and that their drop types are next to never set to tool.

schtserv actually has an error in it's parsing of weapon %'s we never got around to addressing.
we neglected to include weapons that don't appear on a floor as nothing, so as a result schtserv weapon drops on stages such as 1c1 are inflated a bit.

Well the 33% is pretty close though, as that's what I came up with when I did runs through normal mode with the DAR set to 100 like you did. So presumably the meseta drop is still in there as a 33% chance after the DAR check, but since all of the meseta drops for enemies and boxes are 0, it just doesn't drop meseta, ie nothing?

yeah pso pretty much isn't smart enough to not do that. when it can't drop something but selects it, it just drops nothing. There are other examples are stupidity too:
charge special can still drop on the mines floor for example, this may seem incorrect at first, till it happened on psox as well x.x

Oh and more fun, trying to fix the exp steal specials for enemies you don't know what they are till you've killed them lol...

Oh durr, I didn't even think of exp steal in cmode...that WILL be a lot of fun to fix -.-

And as for what you said earlier, I certainly don't mind implementing these fixes into the source for Eden and Ultima. It's not that terribly big of a deal and I need the practice anyways since I'm relatively new to programming. It's not like I've added much anyways; cmode took relatively little to add in. I think the worst part was manually setting the inventories in the server. I wrote a method to do that but it's still quite convoluted and I'm not a big fan of it.

As another question, and be sure not to give me too many spoilers, but regarding the cmode quest files and the spawn locations. Qedit was what actually tipped me off on this: there's a random piece of data just hanging out in the middle of the slot location chunk for most of the episode 1 cmode quests. Kind of hard to explain what I mean, and I'm not sure if your version of Qedit will read it correctly or not. Anyways, it's just this random piece of data in the middle of the random slot chunk that doesn't make sense as an enemy slot, yet the server tries to parse it as such anyways. Specifically, room ID 80 in 1c9, has the big ole pillar in the middle of the room. The server parses that piece of data as a slot (which it isn't supposed to be) and decides to put a slot (a few of them actually) at the coordinates (0,0), right in the middle of the pillar. Now obviously it isn't supposed to do that, and I know PSOX and PSO+ both have this issue, but of course the console versions know what that piece of data is and don't interpret it as a slot.

I guess my question is, what is that piece of data? Kind of starts out like it's a header, but it starts in the middle of the random slot chunk, and just seems out of place. If you want I can go dig up the hex offsets to refer you to exactly what I mean...

I'd have to look at what you mean specifically, but i'm pretty sure we set qedit to parse the cmode chunks correctly prob just the random enemy data, and it's not just randomly there. It's been a while since i messed with cmode quest files.

Btw i set up the challenge mode data structure for qedit. Although it's more incomplete in the public 1.0b version from what i remember.

Well, it's on my list of things to fix up, so for the time being the quests work and don't have those spawns, but I had to remove a lot of the slots for the rooms that were afflicted by this. Qedit, at least the public version, doesn't do edits of challenge mode slots/random enemy data.

How's the stacking update coming along for Schtserv? I presume the issues you had with stacks reverting in the bank/inventory were server side only?

there was an issue server side with techs not updating in the bank and merging, which is when i pretty much lacked time to fix it and shelved it for now (that was a server side issue), the client was actually done and was working fine.

I really don't know what you mean affected by what, I have a feeling you're missing something, when parsing the map data i don't see any slots outside map boundaries and well my qedit obviously allows editing, I remember messing about with the rare enemy flags on the enemy set %'s, could just make all al rappys spawn in cmode for fun, although try killing them with just a saber lol!