I had a problem in the physics demo level that I've been putting together, I had entities that suddenly had zero weight which meant that I couldn't do anything physical with them.

Took me a while to figure out what the failing entities had in common but eventually I realised that it was happening with entity ids greater than 400, i.e. any entity I added after 400 had already been placed, even if I deleted a bunch of entities and added new ones this still happened.

So being a masochist I did a search in the repository code (all of it!) for "400" and after wading through many pages of red herrings found the offending bit of code. Basically due to a simple error in the code only the first 400 entities were having their properties read correctly and subsequently being correctly set up in the game engine.

I went a step further and searched the code again to see if the same simple error was duplicated and found that indeed it was although these secondary occurrences appeared more benign.

Having fixed the ones I found I then reloaded the fpm and discovered that the problem was still there, even saving a new fpm from the old one didn't fix the problem. But a completely new level with more than 400 entities works fine now.

!!! Correction !!! The cause of my problem is that for some reason that I haven't tracked down yet the g_Entity[e].obj value was not set when the level is first run. Some time later the value does get set but this means that the 'init' script for the entity has already been executed.
I have a workaround in my script and I am reworking the physlib to make allowance for this eventuality as well.

So my original map file is working again now!

I will still attempt to work out why the value is not set, even for 'always-active' entities right next to the player spawn position, as this could effect other scripts.

At least you found the problem,and what a great find to.thanks for sorting this one out.

Dave

Sherlock Moses LOL great find sir

Hmm, correction: The bug I found couldn't have caused the problem I was seeing but the new map definitely isn't showing the problem (yet?) whereas the old map is, so I need to dig further.

Somehow the per-entity parameters in the fpm are not being saved correctly so maybe the problem isn't in the loading code but is in the saving code instead. Also maybe it isn't after 400 entities but some greater number and it was just coincidence that all the entities showing the problem had >400 ids?

Anywhichway I'm not convinced I've actually fixed it yet!

good find

Grrrr, now I can't replicate the problem no matter how many entities I use, I have over a thousand entities on the new map all with the pickuppables script attached and they all have weight! I've saved and loaded the map, deleted entities, used the 'i' mode to paint a huge number of trees and bushes down and everything is behaving itself.

The only thing left to try is to edit the fpe files and reload, see if that was the magic ingredient.

Edited to add: Nope, not that either. I'll take another look tomorrow before I pull all my hair out!

Oh, this sounds so familiar when I was using my meager talents to debug FPSC classic. I think I found a bug and then it goes down the same path you are experiencing. Eventually you'll figure it out as I had. If you don't by the time Lee returns, then he will have a insight into it that you don't; mainly, that he wrote the code to begin with and probably has looked at it over and over again. It is amazing how the smallest of issues can create big head-aches.

Aha, the g_entity[e].obj is not set for those entities! Now I just have to figure out why.

Lol brain storm keep at it you will crack it

See opening post for correction, it appears not to be anything wrong with the map file but will adversely effect any scripts that rely on g_Entity values on initial start-up.

Greeting AmenMoses, always enjoy reading your posts.
I do have some questions for you though, even though I can see you have updated your post. And yes this may not be important, more so me being curious.

When building the first map (where you stated you had an issue with 400+) did you edit?
i.e. Apart from assigning scripts, did you place entities with no delete/removal? and was this a long time build/multiple saves. or a one time build/single save?
*also may I ask, was the EBE used?

And the final question,

This may concern the first map, when deleting did you place new entities in the same locations as the ones deleted?
i.e. such as the EBE editor being used on any or both maps? if so, did you count floors, walls in your 400+ ? or was your map say just boxes for testing?

Anyway, look forward to hearing back if you have the time.

The first time it happened I was using a map that has been edited multiple times over several different builds. No EBE involved at all, location of entities shouldn't matter except that on initial start active entities that are over a certain distance from the player may not be properly initialised.

I think the problem is that the engine is trying to be too clever, I think somewhere it restricts the number of times the 'UpdateEntity' functions can be called so if there are too many active entities some may not get updated within a single pass so g_Entity entries will not have been updated. Normally this probably doesn't cause an issue as the update will occur within the next few frames but the 'init' functions are only called once and if they rely on having g_Entity values set then things start to unravel.

I've realised that I've hit this issue before and looking back at some older scripts I actually have comments in them where I've moved certain initialisation code into the 'main' function and added a comment to the effect that 'init' sometimes doesn't seem to get called. I also have a lot ofscripts with things like 'if g_Entity[ e ].x ~= nil then' which hints at the same problem as I obviously hit the case where the script ran before g_Entity entry values had been set.

Thank you for the run down. I've seen a few odd things in the past, though just wanted to hear what your response was concerning your results. Cheers