After trying all kinds of things to get a substitute for landscape triggers, I thought to myself "this sucks, there has got to be a better, easier way." Since my only other option was to rewrite the environmental trigger code in the game engine, I really wanted to avoid it. Alas, some things cannot be avoided forever. Luckily I daydreamed up a stupidly simple hack that would work just fine for my purposes.
I wish I had thought of this eons ago. I dug around in the server code for the section that detects when a player enters or leaves any zones drawn in the world editor. Finding the proper spot to add my fix took just a short time. I then coded a little trigger parser, implementing teleport triggers and leaving it open for any other trigger types I might come up with later.
The trick ( or hack, depending on personal opinion ), was to encode the trigger's specs into the trigger name itself. With this, I did not need to add code to the world editor or client or any of the other engine files. All I had to do to make a working landscape trigger is draw a zone poly on the world editor, and name it properly so the parser can use it.
Finally, after eons of messing around, I had working automatic teleporters allowing travel between my landscapes. It took just under 4 hours to get this new system coded and debugged. I really, really wish I had thought of this before.
Experiments in AI, continued...
After dropping the vain attempt at using NPCs for teleporters, I set about trying various experiments that would (hopefully) lead to some working systems that meet some of my gameplay goals. The first of these involved creating a giant mech NPC that could be controlled by a player. Now, my intention was to not physically mount the player character into or on the mech, the concept was to switch the player's controls and vision from the player's character to the NPC. The game engine's AI script system appeared to have such an ability, but unfortunately it turned out that it was broken. After stepping through tons of code, I found where the system was breaking, but figuring out how to get past it took days. After recoding and recompiling, the control transfer code worked.... sort of. Instead of taking control of the NPC, the NPC began following my character around like a puppy. Releasing control would result in the NPC becoming stationary where I released it. Obviously, something is still missing. I decided to try something else and come back to this later.
Although the results were not what I wanted, along the way I learned some really cool stuff about the game server's inter-service messaging system. This opened up the door to creating my own native AI script functions, which of course I had to try. Suddenly the limits imposed by the list of native AI commands were totally blown away. That made me a very happy Zombri.
The next experiment was to build a morphing NPC. Fortunately this worked pretty much right away. I set up an NPC with an AI running a loop that made it progressively grow through 4 states and then start again from the beginning. Now it wasn't actually growing... I was not deforming the skeleton or resizing the NPC at all, instead I was switching out the model, equipment, and stats (actually, all data associated with the NPC except for the AI instance it was attached to). The reason for this is I am simulating a building's construction phases. The end result will also involve animation and particle effects, but for now I just wanted to make sure I could switch out the model and data properly.
Where are the sparkles and blinking lights?
Next, I got a spaceship model and placed it in game. There it sat, hovering over the landscape. It is a stock model, and came with animation files and particle effects. In order to get the animations and effects to work, I had to attach a skeleton (also provided) to the ship. Unfortunately once I attached the skeleton and loaded up the game, the ship was no longer hovering but was instead crashed into the ground. Sources related to this model noted that the animations needed to be attached in order for the ship to fly properly. I tried for eons to get the animations and particle effects to work properly, and then began to wonder if something else was wrong.
Going back to the basics...
After a frustrating period of failures, I realized the asset pipeline build process was not quite doing its job completely. Related to this was the lack of trees on my landscapes. Personally, trees are kind of low priority for me... but because other issues were popping up, I felt that it was time to try to figure out what was going wrong.
Strangely, the trees were an easy fix. Digging through the logs, I found that the build process was looking for the file that defines where trees are located, but not where the files are that the world editor uses. Simply copying the files from their original location to the location the pipeline wanted them was easy enough... but I have to remember to update them whenever I change them in the world editor. I already know from past experience I'm going to change a bunch of stuff and rebuild like 4 times and wonder every time why nothing is getting updated... and then I'll be like "omg duh!"
While figuring out that issue, I realized some of the other pipeline processes were not operating at all, such as the process that converts all of the character visuals ( faces, eyes, hair, clothes ) and creates color variations of all of these. I had previously only been using models and textures I had manually converted. The last few days have been spent just trying to get this one section of the pipeline to work correctly. Meanwhile, during the lengthy builds ( I have to let the thing run to completion to get the log file ), I am continuing to look into how the system processes the animations and particle effects.
More amazing feats of development (or probably just crazy hacks) to be announced, next time...
the Undead Dev