A new Trespasser patch/update (Trespasser CE)

[DrShaw]

New question. It keep asking for me to put in the game disk. I did install it correctly.

[Lee Arbuco]

Must be some path issue. That happens when it can't find "menu\tpassintro.smk" in the install. Could you post your "trespasser.log"?

[DrShaw]

Cant now. Pc in the repair shop. I don't know when I be getting it back. But sure I will give you the log as soon as I get it back.

[machf]

Added new param to CEntityAttached for ability to correctly attach objects to player (see LevelAuthorReadme.txt)

I'm curious about this, I'm going to read that file and see how it works now...

[Lee Arbuco]

It doesn't do much, rather it prevents something. They hacked into the entity attach code that if an object is attached to the player, it's assumed to be the heart instance (the animated mesh whose texture frame is replaced based on health). To quote their own code comment "HACK HACK HACK".

If no object is attached to the player, then it uses the player mesh as the heart object. This is how the original game does it. But it is possible to attach a separate mesh that is used as health meter, you just EntityAttach it and have animated textures frames like the regular player mesh does.

If you attached a non-animated mesh to the player then the original heart would still work. But you couldn't attach an animated mesh object to the player that you didn't want to be used as a heart/health meter.

What I added was the ability to tell entity attach to just attach objects as regular objects to the player, without any of that special hackery taking place.

[TheIdiot]

It doesn't do much, rather it prevents something. They hacked into the entity attach code that if an object is attached to the player, it's assumed to be the heart instance (the animated mesh whose texture frame is replaced based on health). To quote their own code comment "HACK HACK HACK".

If no object is attached to the player, then it uses the player mesh as the heart object. This is how the original game does it. But it is possible to attach a separate mesh that is used as health meter, you just EntityAttach it and have animated textures frames like the regular player mesh does.

If you attached a non-animated mesh to the player then the original heart would still work. But you couldn't attach an animated mesh object to the player that you didn't want to be used as a heart/health meter.

What I added was the ability to tell entity attach to just attach objects as regular objects to the player, without any of that special hackery taking place.

That's very strange that they would do that. Though I guess it does allow for a separate health meter to be created...nice find. You don't know if it's possible to make an object attached to the player's head (the camera) instead by any chance, do you? Actually, on that note, can the Near Distance be reduced in game so as to prevent object clipping when attached to Anne? This would also fix that shirt glitch you get because of the Near Distance being too low - if I remember correctly, the Near Distance value in Tres's triggers doesn't actually do anything, or at least doesn't work below it's standard value.

[machf]

I was thinking of attaching things to the player's head, too. But in such a way that they track head movement...
Attaching a sort of "visor" in front of the player's eyes and using that as a health indicator (by making it progressively more or less bloody according to the amount of damage) is what we've had in mind for some time... I remember Drac wanted to have Nedry wearing his galsses in that manner in East Dock. Ufortunately, the glasses wouldn't move when you turned your head, so it had to be dropped.

[Draconisaurus]

New beta is ready.

*dances*

Fixed GUIApp terrain TRR conversion bug

w00t!

Fixed GUIApp camera control so looking up/down works (editor cam now works like fly mode cam)

Hmmm, it did work before, you know. I'm not sure how it works like fly mode now, either (checked and standard game controls do not work unless you're playing). Look up is Page Up, look down is Page Down. Kinda odd with the arrow keys... On my laptop they are pretty far apart.

Fixed initial viewport redraw issue after loading in GUIApp

Thanks!

Added new param to CEntityAttached for ability to correctly attach objects to player (see LevelAuthorReadme.txt)

Very interesting. I was a little confused about how the changes work but I've read the TXT file and it seems pretty simple. I wonder why they thought CEntityAttached might be used for the health meter?

Added trigger / action type creation and execution log messages in GUIApp that can be useful for debugging levels (active at LogDevInfo level 10+)

Hmmm, could you explain this one a bit more? (Also curious to know how to know what each LegDevInfo level does, and whether I should just have it on at max all the time...)

Added middle mouse button TresEd-style navigation in GUIApp

Thanks very much for this! However, it's very jumpy in its current state. I have a feeling you would have fixed this already if it were possible but maybe you wanted to get a release out sooner or something. I just feel like not using it in its current jumpy state, kinda distracting. It might be nice if you could add an option to customize the movement keys (including Look Up/Down).

Added GUIApp asserts for meshes with degenerate poly or vertex normals to help track mesh issue

Hmmm very interesting but could you explain this a bit more?

I was thinking of attaching things to the player's head, too. But in such a way that they track head movement...
Attaching a sort of "visor" in front of the player's eyes and using that as a health indicator (by making it progressively more or less bloody according to the amount of damage) is what we've had in mind for some time... I remember Drac wanted to have Nedry wearing his galsses in that manner in East Dock. Ufortunately, the glasses wouldn't move when you turned your head, so it had to be dropped.

Ah yes I remember. I would REALLY like to be able to attach things to the head and have them move along with it. We could even do some sort of HD HUD type thing.
Oh one thing I thought of some days ago! You know how the screen flashes white when the player takes damage? It would be fun to be able to customize this, such as making it red or perhaps display an alpha-using texture of some kind. Might be useful to specify duration in there, too. Should probably go in the .fm stuff but I don't fully understand those yet...

[Lee Arbuco]

Fixed GUIApp camera control so looking up/down works (editor cam now works like fly mode cam)

Hmmm, it did work before, you know.

I was talking about mouse look up/down. It originally has code for looking up/down when holding down the right mouse button, but that never worked.

Hmmm, could you explain this one a bit more? (Also curious to know how to know what each LegDevInfo level does, and whether I should just have it on at max all the time...)

The higher the LogDevInfo level is, the more types of log messages you get. Very roughly categorized by importance. So at level 1 you only get the most important ones, at level 2 you get the important ones plus some a bit less important, etc. but take the definition of "important" with a grain of salt.

If you want to make sure you always get all available messages you can just set some high number like 99.

The trigger/AT log messages are simply log messages that state that a trigger or AT has executed (or created for ATs). Try some level and look at the log messages. There's not much more to it, just something that could be useful for sorting potential issues with a level, to make sure that some trigger gets triggered or AT gets executed.

(Make sure to look in guiapp.log and not trespasser.log.)

However, it's very jumpy in its current state.

Not sure if you mean jumpy when using keyboard movement at the same time. It isn't different for me to the left/right mouse button functionality that's originally in GUIApp. If you use mouse look in combination with other keys like the arrow keys, then it can be jumpy, but that's not specific to the middle mouse button nor something newly introduced. It's just the suboptimal way GUIApp handles keyboard input, which is key-repeat based and not continuous.

Added GUIApp asserts for meshes with degenerate poly or vertex normals to help track mesh issue

Hmmm very interesting but could you explain this a bit more?

Usually a bad/degenerate poly normal is caused by a bad polygon, a poly without area (all verts in a line). If it encounters a mesh with such polys during loading, it will notify about it in form of an assert to make the user aware of their existence.

[Draconisaurus]

Fixed GUIApp camera control so looking up/down works (editor cam now works like fly mode cam)

Hmmm, it did work before, you know.

I was talking about mouse look up/down. It originally has code for looking up/down when holding down the right mouse button, but that never worked.

Ohhh interesting.

The trigger/AT log messages are simply log messages that state that a trigger or AT has executed (or created for ATs). Try some level and look at the log messages. There's not much more to it, just something that could be useful for sorting potential issues with a level, to make sure that some trigger gets triggered or AT gets executed.

(Make sure to look in guiapp.log and not trespasser.log.)

Pretty cool, just tried it out. However there was an error. I was in TestScnNght and it says "DEV: Non-instanced object "MGate02-01" (no template object named "MGate02-00")" It actually prints it in two different places for some reason. Anyway, I just checked in TresEd and both objs are there. They happen to be in the exact same spot.

Oh! I wanted to thank you for updating the latest version of GUIApp to use the enhanced sky. You didn't mention it.

However, it's very jumpy in its current state.

Not sure if you mean jumpy when using keyboard movement at the same time. It isn't different for me to the left/right mouse button functionality that's originally in GUIApp. If you use mouse look in combination with other keys like the arrow keys, then it can be jumpy, but that's not specific to the middle mouse button nor something newly introduced. It's just the suboptimal way GUIApp handles keyboard input, which is key-repeat based and not continuous.

Yeah it seems to have been there already. And hmm okay so that's the reason... Since it is suboptimal, is there any chance you'd care to change it to the other method?


Some other things I noticed... Moving around in the editor no longer moves the player model along with, even when the option is selected to do so (which is still is by default). Kinda convenient (I was always forgetting to switch the option myself), though I would think sometimes it's desired... Maybe change it back and make the default option "Camera Free", with the option to go to "Camera on Player" instead.

Hmm, for some reason it no longer says "Loading (...?)" when loading a level. Pretty sure it used to. Was there a reason to take it out? I kinda liked it.

Also! PLEASE, one of the most important things that ATX gave to us was jumping raptors/dinos. It was one of the primary enhancements to the game, adding all sorts of new dynamics. Some of my best Trespasser moments came from a raptor jumping in some way relative to me. I even had one jump straight at me which caused me to lose my gun on a slope.
[Skyrim]YOU HAVE BEEN DISARMED[/Skyrim]

[machf]

Also! PLEASE, one of the most important things that ATX gave to us was jumping raptors/dinos. It was one of the primary enhancements to the game, adding all sorts of new dynamics. Some of my best Trespasser moments came from a raptor jumping in some way relative to me. I even had one jump straight at me which caused me to lose my gun on a slope.
[Skyrim]YOU HAVE BEEN DISARMED[/Skyrim]

You realize ActJump is now enabled, right?

[Draconisaurus]

Well I would assume it was enabled with all the others... Just finished checking and I cannot get a raptor to jump with this action in CE. I don't think they ever got it to work. I sincerely request the implementation of Big Red's version.

[Slugger]

Well I would assume it was enabled with all the others... Just finished checking and I cannot get a raptor to jump with this action in CE. I don't think they ever got it to work. I sincerely request the implementation of Big Red's version.

Did you add in the ActJump action to the raptor's tscript? There may be a height requirement before it'll jump but the code is in there and it definitely works. In the builds I released the raptors jump, so the problem is either with your level or with the implementation in CE. Big Red's jump was more of a hack anyways, just a probability during the firing of ActBite....

[Lee Arbuco]

Pretty cool, just tried it out. However there was an error. I was in TestScnNght and it says "DEV: Non-instanced object "MGate02-01" (no template object named "MGate02-00")" It actually prints it in two different places for some reason. Anyway, I just checked in TresEd and both objs are there. They happen to be in the exact same spot.

That's what the engine loads. To remind again, GUIApp doesn't "do" anything, it's all the engine. It loads the levels with the same code that the game loads them. The log messages you're seeing are the same for the game exe, except a lot of the messages are disabled there due to being a final build.

There is a MGate02-00 in the GRF, the game however does not load that as a template object, so the log messages are correct. As for why MGate02-00 isn't loaded as a template object, I don't know at the moment. I have to look closer at that.

That you get the log message multiple times is nothing to worry about. Loading is done in multiple passes, and sometimes you can get the message from several loading passes.

Some other things I noticed... Moving around in the editor no longer moves the player model along with

Moving the player along is what caused the problems in the first place. I don't see much point in moving the player along now, since as soon as you enter "play mode" the player is teleported to the editor cam pos, so in the end you get the same benefit.

Hmm, for some reason it no longer says "Loading (...?)" when loading a level. Pretty sure it used to. Was there a reason to take it out?

It didn't work properly and was a hack. It's better off without it. GUIApp is what it is, a non-polished, half-implemented test box. I just tried to quickly patch up some rough edges, but I'm not going to turn it into a well polished application.

ATX gave to us was jumping raptors/dinos.

The ATX action type for dino jump is already there, but the jump on ActBite (the one you have to configure with an ini file in MAPS\JMP) is not added, if that's what you mean?

[machf]

Well I would assume it was enabled with all the others... Just finished checking and I cannot get a raptor to jump with this action in CE. I don't think they ever got it to work. I sincerely request the implementation of Big Red's version.

Did you add in the ActJump action to the raptor's tscript? There may be a height requirement before it'll jump but the code is in there and it definitely works. In the builds I released the raptors jump, so the problem is either with your level or with the implementation in CE. Big Red's jump was more of a hack anyways, just a probability during the firing of ActBite....

ActJump definitely works in CE, I've tried and had no probems with it, just using the default values that are already present in the raptors' t-scripts, only adding the "bool ActJump = true" part. If you mess around with the height values, you may enter one such that it will make the raptor NOT jump unless it's under some very particular circumstances...