mdgunn

The project seems to lack a gitignore file(or it's empty). I am in and out of various files and I find a lot of debris builds up from LW rewriting files and it gets hard to see what I need to check back in. I've updated a gitignore file with the following content which I think should be OK but if any issues please correct and/or let me know. *.brk *.debug *.exe *.bak1 *.meta *.blend1 *.plb forth

OK will see what I can do.

I will look into the sound effects. I noticed the cuboid thing just recently. I hadn't noticed it before. Probably best if it doesn't I suppose as it tends to look more than a bug than not. I will look into it. There should be killing floor (very large box beneath level) which does a reset. I should be able to put this in and for now just send the user back to level start position. Holes in the ground could be random. My initial thought was that there would be many holes initially and then as user comes back more bits would be in place, perhaps more closely resembling a calm looking room....or could be a small cryo like room with single pod, table etc and exit door. Basically simple re-use of current assets so no overhead. I think we mentioned this briefly and not sure if it was going to fit with what you had planned. Was playing with the idea of the cube sort of attacking the pillar as a representation of the struggle and urgency or regaining control of the ship with some lightning between the cube and pillar like this. Maybe just comes on every now and then 4 or 5 times a minute for a short burst of a few seconds. Interested in me putting this in place and if so anything to add?

Ah sorry I usually have it set to push on commit but must have unchecked it on my client. There now.

I'd done part of the change in level3a but then didn't check that one in. I saved back to level3 (not 3a) now. Hopefully this has not lost any of your changes.

Hmmm possibly forgot a check-in yes. I struggle to see the real check-ins required due LW often updating files for it's own reasons. I've been at work. I'll check back at home later. The thing with the use icon and model collapse is easy to get caught out on. Especially as every time I import a model it then needs re-collapsing but it could be that I don't actually plan to touch that model at the time in LW and am really just wanting to export from Blender. Not found a way to make blender collapse it down on export but maybe it is possible.

This map is in Test/prototypes/ship-cave.map. I've had a look through some of the other maps. There are quite a few of them. I was unsure if anyone had intended any of these to be integrated into the game. Some could have had some potential but I think some are lacking the 3D files (e.g. Blender files) so I'm probably not able to work with them and get them into the game in the absence of the original author.

For level 3 I was thinking it would nice to have some particle effects on it with it is inactive and possibly when active. Usually I have something gentle when inactive and something more vigorous when it activates and then the user is moved (possible after a fade to white). It would need some sound effects for teleport (forget if there are any there right now). Possibly some background music like level 1 currently has. Probably should be different track so it's not making you think you are in the dream level. Possibly a background ambient noise as well (e.g. low background rumble or something not intrusive). Are the torch pistol and podium no longer required in the VR bit. I think they have appeared in there in the past and I think I saw the pistol still there? I will add some steps to the cryo room which can be unlocked/enabled by actions in VR as enabling some system or disabling a lock. The things that come to mind (though not fully committed to quite yet) would be Override alarm and bring online minimal emergency systems (physical switch in cryo room/subroom) - Maybe this should enable VR system. Enable health station - wake up initially with reduced health. Reinstate AI ship control - Thinking incoming sphere(from cube) takes over systems and so various things need to be controlled again through manual or VR intervension. - I'm considering some small simple AI room where you would see physical representation of AI unit which would maybe have a robot head as a representation and also perhaps the monolith as the 'case' of the computer the AI is physically in. Unlock cryo room doors Unlock airlock and or outer doors. Supress/Disable Viral control over robot awakenings. After hero has unlocked doors from the second room hangar area there is short air lock room where there can be level switch point if it seems a good spot. After this I have started putting together a short section which takes the hero from the ship through a part man-made natural section (a bit cave-like but also a bit temple like). Will be a few small rooms were there can be a bit of additional combat (cam bots dropping in from vents in ceiling for example) in a controlled area and possibly some info logs to pick up. Here are a few sample shots. This was part of a prototype I did earlier. I am also considering integrating in the the very first map I did to get some reuse out of that. These short rooms would lead up to an excavation area (mostly primitive tech - wood, utensils etc) of local inhabitants. Once up out of the excavation pit maybe we just end here with enemies appearing from protruding vents and the temple area. Beyond this I think we'd be entering into into a different phase of the game. There could be option to fight on a low poly terrain, or to raise the ship up as an 'island' by activating some tech or protruding panels in the local area and then we have some of the island concepts and other design doc sections coming in but I think for a long time I've thought that getting a sort of preview or prequel of what might be a larger game (as defined in the doc) is probably a practical goal. Let me know your thoughts.

I'll look into the things you mention though I have not actually changed ANY of those things on purpose. The green items in level 1 are not really green, they look green because the original level author has a green light I guess. I did not add this. I have purposely NOT tried to change anything in either levels except I removed the black and white filter in level 3 and rotated the light source to match the direction of the sun in the sky map. I think for level 3 I used level3a as it had the altered level geometry already done (and I'd purposefully avoided saving over the usual level3 file) so maybe that was missing the things you mention. I will look into it. Thanks for the information on what seems to have changed though as I have not purposefully changed these things and did not create either level originally so am not familiar with specifics and would not necessarily know if something was not right. This is partly why I held of on putting these changes in and did the examples a while ago in a copy of the level. I will look into these things. I am unsure at this stage if level 3 is considered complete of it needs changes to fit more with going back and forwards to cryo level or something. I think you mentioned coming back and forwards to do stages. If you explain how you saw it happening I can see if I can make it do what you want in your level 3 or leave it to you if you want and I will make the changes to cryo level to match what you want. I still plan to bring everything together and have everything tied together into something you can do end to end. It will still take some more time (probably minimum 2 weeks) but I think there is a finite set of things to do now rather than a more uncertain or infinite list.

Not necessarily final. If people think there is too much, not enough, or anything else not right let me know. This level 3 is maybe a bit busy. Wanted to really fill it up and see what it looked like and if it hit performance at all.

Please don't forget that I believe there is also missing collision documentation as mentioned above. I really think that some information needs to be outside of needing a forum search. Order by date might help too.

Thanks god I'm not being crazy then. I came across this when I was planning to do a Ludum Dare Jam game. This cost me a lot of time and I've had to abandon my submission (which I may have held of on anyway - it was more and informal thing). Well if it is real and it gets fixed then great in the end. This behaviour was REALLY screwing up trying to do checkpoints and respawns as it would just keep respawning me after I'd triggered the checkpoint collision brush. I suppose I could also have had some bad code but it seemed to be this mainly I think.

This is correct.....happens after you hit is once as shown in the video.

For now I'd appreciate it if we can we focus on the provided test case I took the time to put together. I'm not using FPS so choosing a different example with a much more complicated map and different controller seems a strange request. I purposefully chose marble game as it is close to what I am doing and the problem can be shown there very easily (at least for me).

Checked again and the marble game is by default setup to use character. It would be HORRENDOUSLY unfortunate for new users if they then find when they set up a trigger brush that they can get some truly baffling behaviour as a result. The marble tutorial does specifically mention setting up items as triggers (which the coins are but probably lead to no obvious problem). Would be great if Josh could explain how the behaviour that seems to be seen in this issue makes good sense. I don't get it yet. I found your post on the volume trigger. I think this will get me round this. I didn't realise you had published the script for this, thought I strongly suspect I read it way back 2 years ago when you published it. No offence meant to you but I actually find it a DEEPLY DEPRESSING considering the number of hours people might waste trying to locate something like this. I found Einlanders first (which probably also works) and didn't event realise that yours was on the same post. I think it did not show on the page as it was only showing later posts or something. Maybe I just didn't scroll up, but feels to me like it only showed Einlanders post and following responses. I went back to see if I could locate the post and work it out and I can't even see it yet and I have to get back to work. Thanks for supplying the script . Good look to those that have lots of time to try to find these things. Really wish it wasn't like this.

Check over on the collision docs I see this entry https://www.leadwerks.com/learn?page=API-Reference_Object_Entity_SetCollisionType Says .....The documentation of the Collision class provides a detailed explanation of the default collision types and their interactions. Is there a hyperlink to said detailed explanation...nope... check back in help docs to try to find it. Come across this as possibly the doc it means.... https://www.leadwerks.com/learn?page=API-Reference_Object_Collision Which has this content.... This class just contains static members used for collision constants. Constants number None number Collide number Prop number Scene number Character number Trigger number Debris number Projectile number LineOfSight Well not really what I was hoping to find for detailed documentation. Probably the wrong file but I could have not yet found the right documentation. Shouldn't it be easy to find good documentation/scripts/samples on how to do an enter/remain/exit zone in a game?

In your ball game what was your setup for controller (prop?). What's the best way you have of seeing if a user is still in an area or left (e.g. a healing zone, or damage zone). AABB test as you are saying? Having a good example of a zone where you can detect entry exist seems like an essential script in the standard set but I don't think there is one (only a collision which I don't think detects exit). I used to use what was called the entry/exit script, which I was using in this project too but I think it was suffering the same fate where it would keep firing when I wasn't in it. Which I don't remember it doing in the past, though I suppose I usually use a full character controller.

Well I think the collision doesn't fire unless you set it to character. I know you can reconfigure collision types and aabb test is probably a good idea but it really seems like it should be possible via the editor and standard scripts for a novice to setup a basic collision zone without having knowledge of aabb tests. Also, is there really a good explanation for the observed behavior?

I'm on 4.6 seen on both intel and AMD systems with both AMD and intel integrated graphics. Basically I am seeing collision events firing when my character object has passed BEYOND an object which I want to detect collisions on. I see a few collisions fire on entry as expected and then MANY many more on exit which go on for a good few seconds. But then even worse if I let my character rest BUT then move the character object again then there are loads of collision events on the brush (or mesh) I have the collisiontrigger.lua script on even when the object is not anywhere near the object. Could be my setup is just wrong but struggling to make sense of why this behaviour makes sense. To reproduce (see attached files or reproduce according to below): Create an new project with the marble game project. Change the character to be COLLISION TYPE of CHARACTER (is this my error? - even if it is is the seen behaviour not going to be super confusing?) Change the first brush (shown below) to be collision type trigger and switch the script to be collisiontrigger.lua and change it's shape so it's a nice big block across the map. Change the collisiontrigger.lua script so that it does System:Print("*** COLLISION***") as the first line of the method so we can see when collision are happening. Run the level Running the game.... move through the trigger brush...allow the object to stop...move again and brush collisions will fire even when you are clearly not in the area of the brush and there will be many more than you saw on entry. here is a video showing what it looks like. start.map CollisionTrigger.lua

Refined the melee combat with camera robot. Still a bit rough but getting there. Most graphics elements are just stand-ins in case we move to something else (e.g. Plasma ball) if we can make it feel more satisfying or interesting than basic shooting. Seems to be some issue with melee sound not always playing.

Not final. First pass thought I think it could be close to be almost passable for a first release. The under ground object is just a stand-in.

I did try to use the test state function a bit but preferred to just copy in a clean file to get to my level as you've suggested. Thanks for the info.

I think I don't have these buttons set up in the cryo level, just the test levels. I still cannot work with the cryo level and it looks like I will have to rebuild which I wouldn't mind anyway. The code here is not really tied to the code graph. You can call it in code as normal. If you wanted to unlock the door you can just get a reference to the the button that is linked to the door through code and call the same unlock function yourself. You will know how to get a reference to an object I think? Get it from setting up a link via dragging entity onto a public field of the object from which you want to control the target (know what I mean?), or find it by scanning the world for named object (possibly bad performance). Sometimes I will set up an invisible control object (CSG item with invisible/editor-only material on it) if I want to control things in code but have the object visible to editors on the map. -- Get a reference to the self.cryo_room_door_button by whatever means first. if type(self.cryo_room_door_button.script.Unlock)=="function" then self.cryo_room_door_button.script:Unlock() end -- door button should now response to user pressing it. -- You could also open the door without user by calling similar functions on the door itself or calling unlock then open on the button. -- If things done out of order or going round the back then user may not see what expect. E.g. button may say not open but door could be open. Note: things may still be open to some changes. Note: I check the function exists on the script of the object before calling it for safety. Note that in the existence check it is .Unlock(with a dot) but in actual call it is :Unlock (semi-colon). You probably know all this. Maybe you want some more specific info. Just let me know. The doors I was going to avoid being manually open and force opening by a press button which can then open whatever door it is linked to even if has multiple parts.

Interlinked generic lockable toggle button with flowgraph controlled inputs outputs. These are the same buttons. The on/off state of one unlocked button operating the locked/unlocked state of another which then (in this case) acts on the doors, controlling both at once. Flowgraph based maps can be a problem at times (losing connections on changes) but in this scenario with quite generic objects it seems an attractive solution. I'll see how it goes, can always recode to work against references instead. Heres the flow graph. The lights are not fully complete but were going to more clearly indicate that the door was in a locked state at a distance.

Excellent. Starting to look a lot more solid now. Better first impression. Good work!