Egoboo Community Forum

I discovered why the no looping sound bug I mentioned earlier happens. Any object that starts playing any kind of sound as the module begins are not played at all.

Take the following script for example: None of these sounds will be played because they are run at the same time as the module begins.

Some form of that was always done. The messages and sounds associated with spawning characters are suppressed.

We might make an exception for looping sounds since they don't just play once when something spawns.

------------------------

On another topic: the code that makes particles sit on the mesh.

Should this only apply to solid particles (that would be everything like mushrooms and the spent shell casings of the gonne)?

I can't think of any cases where it is necessary for a glowing particle to sit on the ground, but someone might invent a glowing mushroom, for instance...

On the other hand, it would not look good if the missile particle was half-way cut off because it got too close to the ground or to a wall.

There are some spell effects that are stationary on the ground... Like the Skull Trap spell. Gass clouds are also treated as Light or Trans. I don't know how they would be affected by this?

In that case, I think all particles should sit on the ground? I can't remember whether only solid particles were treated this way in the old code. I will have to check back on it.

--------------------

I found the problem with the candle particles. I'm not sure how the original particles were supposed to stay in the same relative position before. They were just spawned at a certain offset relative to each other and the flame particle had a small upward velocity... It seems that they were taking advantage of a particle physics oddity to work.

My workaround relies on the starting z offset to make sure that the particle stays that far above the floor. Right now, it is being scaled by the flame particle size, which is probably incorrect.

Anyway, it looks correct now, and it didn't seem to mess anything else up.

Excellent Another bug squashed (hopefully!).

I am almost done with my module now. I wanted the boss monster to be a bit more unique than he is now (just walks towards players and claws him). I wanted him to grab players and throw them around, but then I would need to add grips and all that which takes forever

So are there 3 levels to the darkness?

There is some kind of crazy fast ghuuul or something that fires poison clouds in the 1st level. You could have more of them!
Display Since you introduced a kind of "mind flayer", in this dungeon, I was thinking that it would be cool to introduce a high tech dungeon. We could make a couple of high tech weapons including blasters and light sabers? There are particle images for those kind of objects, but nothing like them in the game...

Hmm... A technological level. That might be interesting. We could put a lot of G'nome stash in there. The problem with something like that is that we (I?) would need to make a lot of new objects/skins/scripts. We would need new textures for walls, floors and such as well. We could use something from the G'nome Starter. Modifying the Pistol weapon and turn it into a "Lazer" Gun shouldnt be too hard either. Lightsaber something like a glowing sword? (Like 'Vengance'?). Monsters might be difficult... unless we use hyped up techno Lumpkins

I had also this idea of a portal maze (A maze of connecting portals).

I was thinking of attaching a particle to the hilt to make the saber

Something is seriously wrong when you load a module, quit it and load another different module. The two modules get their data mixed up, using the mesh from the first, minimap from the new, objects and passages from both, etc.

I am checking to make sure that the data is definitely deleted and cleared after every module. The function game_release_module_data() seems to be called every time.

All of the mesh memory is freed and then the pointers are all set to NULL using memset, so we can't even access the old data by mistake. The passages were not specifically being reset on module unload, but I am updating that right now.


If all the various parts of the module are coming from different modules, it sounds like a problem with the virtual directory system and PhysFS. Like maybe the directories are not unmounting when you go to a new module. Did you update PhysFS or something?

No, I did not change anything. I updated to the latest revision, cleaned and rebuilt... it still happens! This is whenever I start playing Imprisoned One I and then switch to Imprisoned One II. I'll upload the (unpolished) module so that you can check it out yourself.


I also noticed some sort if particle leak like we had in Imprisoned One I before using all the free particle slots. I haven't been able to track down the source yet.

I noticed that some of the ripple particles in the advent starter are not despawning.

Is it after you complete the module, or are you just exiting at random times?

----------------

I still can't duplicate your problem.

I think I may have fixed one of the particle problems. Ripples were spawning ripples or something like that, and it was making the particle cound go crazy. It would only occur when there are weather particles and water, so not every module would be affected.
DisplayI did like the air vents in the cold room. very fun to get shot into the air. Also, the dividing cube is very interesting. I think we have to make it so that it is possible to jump to dismound a cube. Otherwise, getting too close to one is a death sentence. There is a problem with the mind-blah particles not shooting at my character. It may have had something to do with not having enough particles, though.

I'm thinking of disabling the grab effect for that cube. It's just something it inherited from the Gelfeet. I never planned it to suck things up. Maybe it sucks things up, deals damage and then drops them again?

The bug happens at any point where I exit and then start the next one.

Wow. This bug is pretty unique. I tried playing various modules after each other and the only time this bug happens is when I first play Imprisoned One Part 1 and then load Imprisoned One Part 2. Happens every time.

It seems the old spawn.txt is used, the new minimap, objects from both modules (local objects from both overriding global slots used). Local objects from the second module seem to override the first module. According to what you've said, this should not be possible at all!

Yikes?!

[edit]I managed to play without the bug once (randomly). But the bug also happened the other way around, Part 1 mixing with Part 2. (Instead of Part 2 mixing with Part 1).[/edit]

Is this happening only in the release version or in the debug and the release versions? It could be some kind of uninitialized variable in the release version which would explain the random behavior.

-----------------------

I was finally able to duplicate the bug! Now to see what is causing it...

• INFO: Resetting module data
  INFO: Loading module "modules\imprisoned1.mod"
  WARN: md2_rip_commands("c:\Projects\Ego\zefz-sourceforge\branches\2.6.x\modules\
  imprisoned1.mod\objects\swampplant.obj\tris.md2") -
  Number of OpenGL command entries exceeds preset maximum: 1358 of 512
  ---- mpd_load("modules\imprisoned2.mod\gamedat\level.mpd",0012FD8C)
  WARN: load_one_profile() - Not able to open file "objects/sandtroll.obj"
  WARN: The object "sandtroll.obj"(slot 83) in file "data/spawn.txt" does not exist on this machine
  INFO: net_initialize: Networking not enabled.

-----------------------

I tracked the bug down. It has to do with how PHYSFS and the vfs system tried to remove the old paths from the search list. I'm working on a patch right now.