Classic Entities Mod
xDragon
Join Date: 2012-04-04 Member: 149948Members, NS2 Playtester, Squad Five Gold, NS2 Map Tester, Reinforced - Shadow
Join Date: 2012-04-04 Member: 149948Members, NS2 Playtester, Squad Five Gold, NS2 Map Tester, Reinforced - Shadow
in Modding
I recently published this small mod which adds some familiar entities from NS1. This is similar to Extra Entities Mod (and even designed to support maps built for it), but is more focused on a smaller core set of entities.
The code is available at https://github.com/xToken/ClassicEnts. I welcome anyone that does try this out to let me know about any bugs or issues you encounter. Included is a small demo map which shows of some of the entities and how they can be used.
The mod can also be found on the workshop at http://steamcommunity.com/sharedfiles/filedetails/?id=474696302.
Included is an editor_setup.xml file for use with the editor to allow placement of the new entities. This file also contains the entities from WaterMod, which would need to be run if you use those.
Here is also a brief overview of the new entities:
Breakable Emitter - A breakable entity that can be scaled and use models from props. Emits a signal when broken.
Controlled Button - A button that can be signaled on/off. Emits when used. Also can be scaled and use prop models, or restricted to only a specific team.
Controlled Moveable - A entity which can be given a model and scale. Will path between provided waypoints given, using initial location as first waypoint. Allows 3 object types - Gates open and close only by signals. Elevators path between multiple points before returning to original. Doors open/close automatically when players are nearby.
Controlled Timed Emitter - A entity which will emit a signal after a certain time. Can be used to chain events.
Controlled Weldable Emitter - A entity which will emit a signal when fully welded. Can use prop models and be scaled.
Controlled Dialog Listener - A entity which will show a message to local players or globally when signaled.
Function_Listener - Can be used to trigger LUA functions when signaled. Let me know if additional functions are needed (have to be added in code).
Pathing_Waypoint - Used by moveables, takes a number which indicates their position in the chain.
The code is available at https://github.com/xToken/ClassicEnts. I welcome anyone that does try this out to let me know about any bugs or issues you encounter. Included is a small demo map which shows of some of the entities and how they can be used.
The mod can also be found on the workshop at http://steamcommunity.com/sharedfiles/filedetails/?id=474696302.
Included is an editor_setup.xml file for use with the editor to allow placement of the new entities. This file also contains the entities from WaterMod, which would need to be run if you use those.
Here is also a brief overview of the new entities:
Breakable Emitter - A breakable entity that can be scaled and use models from props. Emits a signal when broken.
Controlled Button - A button that can be signaled on/off. Emits when used. Also can be scaled and use prop models, or restricted to only a specific team.
Controlled Moveable - A entity which can be given a model and scale. Will path between provided waypoints given, using initial location as first waypoint. Allows 3 object types - Gates open and close only by signals. Elevators path between multiple points before returning to original. Doors open/close automatically when players are nearby.
Controlled Timed Emitter - A entity which will emit a signal after a certain time. Can be used to chain events.
Controlled Weldable Emitter - A entity which will emit a signal when fully welded. Can use prop models and be scaled.
Controlled Dialog Listener - A entity which will show a message to local players or globally when signaled.
Function_Listener - Can be used to trigger LUA functions when signaled. Let me know if additional functions are needed (have to be added in code).
Pathing_Waypoint - Used by moveables, takes a number which indicates their position in the chain.
Comments
If you have it set to Elevator the following things will happen:
1. Running against a wall while the Elevator is moving will allow the player to glitch off the elevator, falling through it.
2. The Elevator can move over the player freely. For example, if the player is on bottom waypoint for an Elevator and the Elevator is currently at the top, triggering the Elevator will drop the elevator and it will pass through the player until the player is effectively on it.
3. When the Elevator is moving any direction except up/down (diagonally, for example) and the player happens to touch geometry while it is moving, the player will end up being pulled in the direction of the elevator and will become effectively stuck unless the Elevator pushes the player back out when retuning to its original position.
Aside from that, one nice-to-have would be to set the trigger radius on a Controlled Moveable set to the Door mode.
Elevators are still really buggy overall, or at least the player interaction part of them. The clipping through players I don't have a good solution for yet, I haven't decided if its best for the elevators to outright kill the blocking player, damage them a bit and bounce back, or just clip through like they do now.
I suggest you add a Blocking type with different options and allow it to be map configurable:
1. Kill blocking entities.
2. Reverse mode. If the elevator encounters a blocking entity, return to the last way point.
3. Ignore and pass through entities.
I updated the moveables also which should resolve *most* of the issues with elevators and players riding. Its not perfect and there are a couple edge cases I probably need to account for, but I can fix those hopefully much easier from now on. I added a new property for them called blockedDamage, if its greater than 0 they will cause damage to blocking players. I made all of them blockable because they were causing issues for prediction when they just clipped through players, and they could get you stuck. They currently do not get blocked by structures however.
I also added the detectionRadius for moveables that are doors.
No promises on "When" though. Good work @xDragon! I'm all for giving mappers / modders more and better "tools" to work with.
Actually, I am not sure how it appears from a third person perspective - IE someone watching someone else ride the elevator.. Kinda hard to test that solo
Generally I found running in third person mode gave similar results to what others saw in game.
https://youtube.com/watch?v=e3iTrMlIRr8
The problem with lag compensated games and moving elevators is that each player shown has its own timestamp; when you watch a player you are not seeing the player where the player is now, but where he was some time ago.
Normally this is not much of an issue (apart from killed behind the corner thing), but when the player is standing on an elevator, you get a problem.
The elevator and the player will have different times, so the player is standing on the elevator where the elevator was (100+latency) ms ago. So to watchers, the player will either be standing knees high in elevator (if the elevator moves up), or float half a meter up if the elevator is moving down.
To the player standing on the platform it will look fine though (because the player is moving through a world where he is synched with the world time - it is just that it takes time to transmit his position to other players, at which time he is no longer synched).
This is not limited to just "standing on" stuff either. If a lagged lerk flies just above (without touching) a raising elevator, to watchers the lerk will be flying straight through the elevator.
Likewise horizontally moving things. A player standing at the rear edge of something moving horizontally will be seen as standing on thin air.
I do have a handle on how to solve this; it involves having players check if they are in a position where they are affected by something moving, and then adjust the players reported position to be relative to the moving object. So a player standing on an elevator would have its visible position adjusted (by the server) to be relative to the elevator instead of the world origin.
Of course this leads to transition issues when a player goes from world-origin to elevator-origin, but a bit of smoothing should help there.
The cheap way of doing this would be to place the player as a child of the elevator (because then the player origin becomes relative to the elevator automatically), but from looking at the code, pretty much nothing would work correctly if you did; all the code assumes that if you do a player:GetOrigin(), you get a world origin offset.
What I have been looking at is manipulating the _velocity_ of players rather than their position. It solves the problem of elevators shifting players into geometry (because you are not changing the position of the player) and it also helps solving the issue with players jumping off a platform (they still have the velocity from the platform even when not touching it; then you can bleed off the velocity afterwards).
Kinda tricky to get it right. Makes you wish that NS2 had proper momentum/friction based movement instead of it all being faked.
There's also still a lot of collision issues even if the elevators just add velocity, since you have no immediate feedback on if the player should be blocking the elevator. You can make them simulate their own collision as they move, but that quickly becomes a huge mess with vertical ones. If its moving down then you really need the players to move after like they do, but if its moving up then you will constantly collide with the players who are riding.
So yea, there is a bunch of things that needs rewriting.
And you need a "OnPostProcessMove" callback from the engine which are triggered in the world timeline (ie, after the elevator platform has been reset to world time) which allows you to figure out the size of any position offsets needed to make things look good for other players.
Was working on it when the buildmachine went active, so had to switch to focus on 275 and 276. Maybe I'll get it done for 277 (which should be this year).
And sorry, I don't really know of an easy way to get a generic model collision working. The player movement uses simplified models (capsules or spheres) to represent the player when you do PerformMovement. Box trace is your best bet, but how to get the accurate size of the box can be a bit ... difficult.
The box trace works well enough for that part tho, just looks a bit goofy at times.
But right now we have no support for structure-on-structure collision; they are not supposed to move at all.
First comment is:
can you add the option to make the entities, such as lift entity, invisible to commander. I added it to the commander invisible group but it didn't work.
Second comment is:
A commander is able to drop structures (such as armoury) on the Controlled button entity. This allows for half of structures to be placed in the wall or even block the button by the commander.
If the entities can be made invisible to commander, then maybe this can't happen?
Would be great if you can add the suggested feature