A new Trespasser patch/update (Trespasser CE)

[machf]

GUIapp had an option to display FPS, among other things. Is it sill there?

[Lee Arbuco]

Sure, but keep in mind that GUIApp is not built in final configuration so it could be a tad lower than in the game.

[Draconisaurus]

Huh, well that's something. Just found where it is - thanks! Should be helpful since they are at least very similar, GUIApp CE and Tres CE.

[Draconisaurus]

A note on the HUD - it will be vital for levels containing a male player character. With Dennis Nedry, we were able to create vocals using sounds from the film, but even then he did not have ammo counts. It's important for the player to be able to know how much ammo they have, unless that mystery is part of your level design. Pretty much the only way to do this without the ammo count would be a HUD.

[Lee Arbuco]

Just from a hypothetical standpoint, it would be possible to solve it in a different way than with ATX style HUD support. Something that is more true to how the original game works. Whenever there's a player vocal about ammo count (or supposed to be one), the game could display the ammo count in text and/or icon form, in some nice semi-transparent look in a corner which then fades out again after a second or two.

That would be a HUD counterpart of how the game originally works through audio, in that you from time to time get temporary info on the ammo left. Making this a built-in feature would also allow it to be enable for all original and user levels alike, which would be helpful for hearing impaired players as well.

[machf]

Sounds like a reasonable option.
As long as it doesn't interfere with other texts displayed on the screen...

[TheIdiot]

Hmm...would we be able to get support for a health meter too without needing to look at your boobs every time you get hit? I feel like the old ATX style HUD was an excellent solution, unless it's too hard to program back in. I also agree with Draco, we need an FPS display without using an external program - even just a simple little counter in the corner available in Developer Mode would go a long way, especially since Fraps or other similar software is known to cause game lag and slowdown on many computers. Knowing [FPS] is half the battle!
One extra feature request, Lee - would it be possible to make it so rendering related triggers which usually only work as Start Triggers, such as Ambient Lighting and Clutter Values, work mid-level? Being able to change lighting conditions and game color could help a lot for creating "dark" areas or even time of day changes during level design.

[Draconisaurus]

TI beat me to it. Ammo count is only part of the HUD - there's also hitpoint display. This seems important to me in JPDS, as the health system works differently and it's potentially important to know how much health each of the various items provides, how quickly (or whether) your health is increasing or decreasing, etc. The mod TI and I are working on will use a similar health system. I do like the idea of a semi-transparent option for the HUD, though.
Mmmm. This does raise the point of a key to display or hide the HUD. ATX uses hotkeys (including optional) for certain things. Oh and the aim dot! PLEASE return the aim dot! I basically learned to aim in Trespasser using that dot. Aiming in Tres has always been tricky; the sight line-up does not always work, and gets worse with distance.

especially since Fraps or other similar software is known to cause game lag and slowdown on many computers.

Thanks a good point I hadn't thought of..

One extra feature request, Lee - would it be possible to make it so rendering related triggers which usually only work as Start Triggers, such as Ambient Lighting and Clutter Values, work mid-level? Being able to change lighting conditions and game color could help a lot for creating "dark" areas or even time of day changes during level design.

This sounds nice. Doing it this way *might* be simpler than attempting some advanced engine maneuver; let the level designers work it out manually (though this should be tested of course). I've seen that shadows can be updated at least in GUIApp while you're not playing, as you move lights around. Of course the sun would need to move... that part sounds advanced. And then the replacement of sky textures... introduction of stars... hmm.

[Lee Arbuco]

As you can also notice is that the framerate drops radically when you change the light on a normal sized level where you have a bit of a view, and changing light intensity doesn't properly apply on terrain in HW mode or impostors, that's because the lighting isn't fully dynamic. When it changes, caches have to be flushed. The engine isn't geared toward dynamic updates of the lights. I'm sure it would be possible add clever schemes to force cache updates in small amounts for slow changing lights, but it's certainly no free lunch.

[DrShaw]

I been wondering. How many polygons can be shown on it before it become unstable?

[Lee Arbuco]

I'd say it can handle more than there should be to sustain a playable framerate. The limit is 80,000 polys, and by that time you're likely to have a single digit framerate. Even when it exceeds that limit it's not suposed to crash anymore, but there were a few issues left in that regard that I fixed for the next update. I hope those were the last ones.

Usually when poly counts are too high for a level, you want counter it by reducing quality settings to maintain playable performance. Reducing the distance at which objects turn into impostors and things like that.

[DrShaw]

80,000? Wow. Thanks because I'm going to start making levels soon with help.

[Lee Arbuco]

I want to make really sure there was no misunderstanding. 80k is the memory limit of the pipeline, above which polygons start to disappear from view. It's not a guideline for how many polys the engine can render at an acceptable framerate. For an acceptable framerate you need a lot less polys than that.

[DrShaw]

Ok then. Understandable.

[Lee Arbuco]

New beta is ready.

Changes:

Fixed some remaining crash issues when overshooting poly render limits
Fixed GUIApp terrain TRR conversion bug
Improved assert behavior in GUIApp ("SilentAssert" option in trespasser.ini can be used to disable all or show all, asserts are logged)
Fixed object lighting when disabling bump in GUIApp
Fixed some path issues with GUIApp
Fixed GUIApp camera control so looking up/down works (editor cam now works like fly mode cam)
Fixed initial viewport redraw issue after loading in GUIApp
Added new param to CEntityAttached for ability to correctly attach objects to player (see LevelAuthorReadme.txt)
Added trigger / action type creation and execution log messages in GUIApp that can be useful for debugging levels (active at LogDevInfo level 10+)
Added support to specify recommended quality settings for user levels (via fm.ini)
Added LOD info and current estimated screen size of object (value that can be used for LOD thresholds) in GUIApp object props dialog
Added middle mouse button TresEd-style navigation in GUIApp
Added GUIApp asserts for meshes with degenerate poly or vertex normals to help track mesh issue


Edit: Attachments removed because they're outdated.