mdgunn
-
Posts
626 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Posts posted by mdgunn
-
-
I was hoping to get away with just the one map if it can be made practical. I saw it working something like this. there is a pivot which has children which are all the bits that need to show and hide at each stage. Turning on/off the pivot will show hide the children and make them non-collidable. To get the final look you just turn on all the 'stage' pivots. If you want to modify the contents of any stage you just drag and drop one item from one stage to the other. It could be that in practice this is a pain and not practical if there are lots and lots of items but in principal it seems like it might work and others could tweak at editor level rather than needing to dive into codes or try to compare and sync different maps.
I'll give it a test when I can and post back.
-
Sorry I didn't explain to well to bring everything together. My thinking was that we start with the level with holes as we have now. Then if we are to return to VR room several times then the room changes over time simple by moving missing blocks back into place and showing previously hidden final room items. For example, the floor starts with blocks and the current electronic looking texture but a few hints of normal final structure, like a few standard black floor textures and perhaps a desk or stool in place.
Next time we come back we would unhide more 'final' stage items, more flooring filling in gaps etc. Eventually the room is in something like shown above (probably not that exactly). I took the basic room dimensions of the room actually from the current VR room.
The current level 3 is supposed to be virtual isn't it? The virtual room I show above could look even more virtual and impossible but I also wanted it to look slightly real like the rest of the ship though it doesn't need to.
I was thinking that the virtual final rebuilt VR room could also look like the real world VR room counterpart. Or, it be the room that houses the AI computers rather than specifically a VR specific room, but seems sensible that in an AI computer room you'd definitely have a VR link and when you go into VR it might well default to looking like a cleaner virtual version of the room you came in from.
I'm open really. I thought I'd explore it. It just provides an easy way to help ground our levels in a coherent environment.
If you'd prefer to just leave level 3 as is and keep it looking MORE different so that everywhere does NOT look the same then also fine with that. I may at least use this room as a room to house the AI computer where you go to before you exit the main ship.
I am also pushing forward a bit on the bit outside the ship and am still conscious of moving forwards to an end point rather than adding on too many new things.
-
Exploring the idea that the broken up level becomes less broken as tasks accomplished. This is first test example of what final room might be like. Trying to get a basic feel. Want it to be fairly sparse room with a calming waterfall and somewhere to sit with a VR version of a comptuter and the AI present as the monolith and heads. There could be counter part room (based on this one) in the real work with the monolith (acting as the housing of the computer AI) along with more cluttered physical environment (few cooling pipes) ventilation vents, additional computing cases or exposed motherboards in processing stacks . Would be a simple room where you might complete a manual task (e.g. to restore final AI capabilities). Room might be at far end of second room and maybe you do manual action in order to be able to allow the AI to get the outer doors open or something..
-
Great! You're welcome.
-
Detect it? Does it do that? I never keep my projects in the default location though. I always do 'Import' and locate the file. Is that not working?
-
1
-
-
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-
1
-
-
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.
-
6 hours ago, aiaf said:
But i dont see the changes you did with those many cubes around, maybe you didnt commit it yet ?
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.
-
5 hours ago, Josh said:
Does this occur in the door FPS example? There is a hidden trigger field there that opens the second door.
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).
-
14 hours ago, reepblue said:
Does it do this when the ball is set to Collision::Prop? How about the character controller set to Collision::Character?
I have successfully created my floor buttons using the collision function and experienced no issues. I do an aabb test of my off touch detection, however.
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?
-
1
-
23 minutes ago, reepblue said:
I have successfully created my floor buttons using the collision function and experienced no issues. I do an aabb test of my off touch detection, however.
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.
Release ?
in General Discussion
Posted
The camera will be moved a bit if damage is taken though we could try to do some other things.
I might have commented out the screen blood splatter effect that comes normally with controller. Could either put back in or icon fine too. Blood splats can sometimes be a bit over the top. faint red vignette maybe better. I don't have a great preference.
I did not look closely at the spell stuff, only to the point that it did not seem to be quite working but almost was. I had a lot of other stuff to tie up so not got back into it but I did meant to say (and I think I might have mentioned it in a post) that it would be nice to get some of the existing stuff back in that was part done but I was not around when a chunk got added so I don't know what it's status was (I mean, just a test or if it was the start of what was to be a final level) or prop.
Maybe if some people are reading this they can comment?