mdgunn

Are you on the beta branch? I had an error just now when I was on the Beta branch but complaining of an error in Button.lua. I'm back on the non-beta and my build starting without error.

Been away for most of xmas so far. Hope to get back into things in the next day or so (been rather ill yesterday). Will check this out.

Wasn't there something in the workshop with some modified shaders that were aligned (more or less) with substance painter exports?

OK. Not meaning to disrespect your idea. They are not bad ideas and as you say may have been relatively easy to do. It's not that I want to ditch the story but I think it may be best if some of it is backstory we know about but we try to mostly let things unfold through action. The story is still a good way for us to have a common idea about what is going (the back story) even if we leave it a little less clear to the user where it may be enough that it is clear they need to do a thing because they need to not die, rather than because its exact position in a larger picture. Maybe. I'm no narrative expert. Currently I guess in my mind I am trying to also see a way to get to a 'milestone' point as I think you are. A position where we have a demo of sorts. I think I don't know for sure if this will work out but I think I would do would be like this:- - Refine your dream section a bit. Maybe re-using some ship models for wall, floor etc. - I finish cryo room modelling. Add in some simple interactions like your dream room, such as a) turn of alarm, reset systems, get info on initial task (stop incoming drones waking rest of ship). - Secondary ('solider' cryo room ) - can re-use bits of first. Small enemy skirmish, disable wake-up machinery, gain hand-weapon. - Simple key quest to open outer door. Move through a few simple rooms and corridors. Enemies can pop in with simple spawn mechanics. Hand-weapon thaw-freeze might be used to activate or freeze mechanics or hazards. - Exit ship to island and navigate island natural environment and deal with incoming enemy threats around a few key locations (e.g. exit, village etc.). - Get to some key ship location at other end of island (e.g. escape fighter bay). - There can then be a reversal of sorts of entering ship navigating corridors and then entering key room (control room/fighter bay - maybe we go to both). - I think at this point we then end after a last fight enemy fight in fighter bay or in escape fighter protecting our bigger ship or something). I am not cross-referencing doc when putting this together so it might not quite fit what I said there but in general I think maybe the outline above could work. This is still quite a lot of work. If you have any interesting mechanics then they could be brought into one of the items above or replace it. Not trying to dictate the exact path here so if you have suggestions please let me know. If you want you could propose an alternate way of getting to a natural end point and we can merge things together.

Interesting ideas for sure. Not sure our player would understand what they are doing. Currently I am imagining the things are coming from space are not the monolith but these smaller these numerous activating spheres. These are like little simple drones sent in large quantities. They are like little seeds. They are getting scattered across the planet. If they land near a ship/island they can burn/bury down in the ground down to the ship and enter the ship. These might be about 50-75 cm across and I had imagined inside there might be a sort of power core sphere and that the freeze/thaw weapon is taken or merges with our character near the start when she stops her own ship waking up, by blocking/destroying the incoming spheres in a second room (or room near the start). At the minute I had imagined that this process had happened already (a sphere had entered) and this was maybe what had woken up our character as she had set this as an alert event before she went to sleep. Could be that the island starts submerged and no sphere yet and we start a bit further back but although showing all these earlier things might be cool it's probably a lot of work and best at this point to work forwards with some easier game mechanics until we have a few things tied together. If need be there could be static images and text that tell this earlier story. We have to watch how big this thing gets. Could STILL be that the monolith also came from space, perhaps it is like an AI/computer inside also sent in response to the awakening spheres and that this has been sent to trigger the characters awakening. I think narratively it might be confusing that in the early stage you seem to actually BE this monolith - the player will automatically associate controlling a thing with being the thing I believe. And then you're not the thing and you're this other person. I think it might be best to avoid a lot of the story telling, but avoid things that might be confusing (e.g. switching characters). I'm not saying ditch all the story so far. It's still important for us to discuss these things as backstory. I think it's useful, but I think we should be careful about actual show and telling to the player.

Yeah I'd destructible objects was something I'd considered. I've had the mechanics for this working before (an object which can take a certain amount of damage before getting destroyed). The bit I didn't do was the actual visual destruction (falling apart) with physics looking right for the destroyed bits. Should be possible but can't say I've done that.

Way back I think there has been mention of possible fire and ice spell/effect/weapon. I've been thinking about this a bit. I'm a bit wary about combat with AI being a possible area of long term interest for the character, and problems in implementation (e.g. AI getting stuck on walls etc.). I was thinking that maybe this freeze burn mechanic might be useful as a puzzle element (and also in combat). In theory it seems that it would be fairly simplistic to use this freeze burn(thaw) mechanic to start stop physics based elements (e.g. using a motor), or perhaps to just use programmed step motion (meaning not physics based). WARNING: I could be very wrong and it there MIGHT be a lot of hassle in trying to pause and resume physics based processes. God of War had some good use of ice and fire in both puzzles and combat. Could be an area for future thoughts if anyone has any. As far as combat usage I did do a bit of testing with item effects (e.g. poison, burning, ice/slowdown) some time ago. Don't think I got it finished but I think it looked like it was going to work out OK. I think I basically passed an effect along to the usual Take Damage function and then use it to apply a setting on the object and start a timer if it was going to be a timed effect (e.g. poison). Anyway, something to think about.

I'd been thinking the same that the minimalistic style as the first level might be jarring if it is lengthy and different to rest of game. However, I also thought it was quite a neat idea of having some pre-wake up sequence where something is happening to trigger the character out of deep sleep. I believe there's something similar in Prometheus? So, at the minute I would not totally rule out a short dream/wake-up sequence but I think it would have to be quite interesting in it's environment visually but also short. Could then be introduced in a more significant way later on as you say. I like you're thinking here. Maybe there is scope for some simple puzzles and info gathering within rooms and corridors on way to surface?

Did a quick test with the lights tutorial level. Seemed OK even on high though I'm on Vega56 now. When I originally played with it way back (generally actually avoid it because of past experience) It seemed to have increasingly negative impact beyond the first several clicks up from zero (before half way I seem to recall). Perhaps it is not the volumetric light itself but it's effect on other things such as certain shadow settings. Could be I was on a limited laptop GPU in some of these experiments so maybe this was also a factor. Maybe it operates differently these days. Anyway I'm really pretty sure I wasn't imagining things. It did seem something was occurring. Very possibly side effects of bad setup, but then how would a new user know this if it can be this?

Yeah volume light is SUPER SUPER heavy on FPS. You can almost get away with it if you keep the setting very close to minimum. If it was present it would probably need to be something that could be specifically toggled off in settings or with a low/med/high setting and it only on at high.

I can try and do some particles for the teleport if you want me to try that bit. Here is a vid of some I did a while ago. I've probably lost the assets I used here but I can recreate.

Revised teleport pad. Nothing fancy. Think you will find in Prefabs/Architecture/teleport_pad_v3

You can change the scale of the instance in one or more directions to adjust apparent if you just want it smaller in a certain direction but yeah it's pretty awful . It was one of the last ones I did. so after doing all the rest just wanted to get something out and stop modelling for a bit. Maybe I'll just do a teleport pad with just a bottom bit. If you wanted any more props or wall/floor elements and stuff like that you can let me know. I don't want to get hung up on trying to finalise lots of models but prototyping some fast ones (e.g. untextured) that even might get thrown away may help solidify a style. So, just let me know if there's anything else. Don't mind doing alternate versions of any, though I might shift focus back to other things for a bit too.

I got it working There are a few things needed for things to work out. You need a property named 'enable' on the script attached to the object you want to use/trigger You also need a method named use in that script. Like this... Script.enabled = true--bool "Enabled" function Script:Use() System:Print("USE CALLED ON TRIGGERMAPMUTATION") end You will find these present in your working script. The other thing is less obvious. The other issue here is that I had to collapse the model. I think in some situation you don't want to do this and I may need to work with this a bit and understand what is going on. I think basically the top level object of the teleport is probably empty like a null or empty so there is nothing for the raycast to hit, even though physics seems to be on. It is probably ON on the lower level objects but not this top level object. By ON I suppose I mean the physics are really defined for this lower child object but there is no geometry at the root for there to be anything to be hit. I think when you collapse the model all the geometry that might be on lower branches all end up on the root so a raycast will hit it. Sometimes you don't want this. For example I think you could make it so that you have a hitbox specifically setup on the HEAD of a character which might be a child of the body. You can then specifically detect headshots if you do the right programming. For the simple raycast that the FPS controller current uses I think it is probably simplistic and just expects to hit something at the top level where the script is attached. So in summary 3 things needed: 1) Collapse any models in model editor if relying on simplistic FPS use/raycast check. 2) Add enabled property to the script (Script.enabled=true--bool "Enabled"). 3) Add Use method to script (Script:Use() ) Any problems just get back to me. It's useful to work through these first teething problems.

FYI Josh: Unsure if it's connected but there was a recent FBX issue in the forums. They struggled with importing the tutorial assets. Got a bit better results on an old version 4.1 but never got current version working properly I believe.

Probably Props collision, but have you added a collision type to the MDL file in the model editor, if not set there to be box, or object mesh etc. then the RigidBody type doesn't have any physics mesh to collide with. On way out so can't check your example but may have time much later when back.

Though 'dream room' might have been interesting if it had a sort of abstract geometry or even abstract maze you progress through as you unlock info or items or something. Like the walls or floors retract or shift as you progress (maybe that is frustrating and confusing)....thinking a bit like bound (PS4 VR game). Just an idea though .

Gonna have to head out. When things are entities I think FindEntity may not find them as I believe they actually don't get a name value if an instance. I'm, not sure there is a good Leadwerks reason for this, I was surprised by this too (if we are talking of same thing). It sort of makes sense, if an instance it is not really a full proper copy. May be a way to get round it (in script). I think the easiest thing is if you just go ahead and break the prefab link so it is a full instance (just edit a property to get the dialog up). Keeping prefab links in place is something to watch out for as we further develop but for now a few broken links are OK and probably necessary and quite reasonable so don't worry to much, especially for unique objects. Where we have genuinely lots of copies of something then keeping the link can be more important.

There are already teleporter with particle effects in the Addon directory. I didn't want to replace your own teleporter with my own. If you want I can do this but my goal was not to get into particle effects but just the model as you can probably appreciate. I have done a good bit with particles though and may have some presets to try so if you want me to do teleporter particles I can just let me know.

Yeah this is normal. You can break the prefab link and make an instance if you want, or you can open up the prefab (like a map) and modify that if you want if for example you want to add default script properties that make sense everywhere. I have focused mainly on just getting the models ONLY into Leadwerks. There are no physics on the objects. Select the MDL file for the object you want (the monolith) and assign a physics type that fits what you need (e.g. box may be enough, try a few). I have not made all these decisions. I leave some of these choices for who want to use the objects more in their scene than mine. We may need to tweak the physics types later. Moving to model objects provides a large time sink to me if I have to rework objects, re-import them set up physics again, reassign materials etc. Really moving to models represents a real risk to progress forward. Moving to objects and doing these models means I could not complete the other things I had planned. I would like to see more modeled environments too but it's important to appreciate the time that got diverted into me generating about 15 objects rather than spending the same time elsewhere. Don't mind doing the models, it was fun but it DOES represent potentially a lot of time diverted.

By the way....I HATE the teleporter! Looks like a shower. Some of the others are a bit meh, and I'd redo but for now they provide stand-ins should anyone want to us them. There are more models than this also. Check the directories mentioned, there are also the wall floor and ceiling panels and pipe, cyro pod etc. Basically the VR test room is constructed from panels of power of 2 based geometry (e.g. 512x256). We should keep focussed on mechanics though rather than going to far with models till we have maybe 3 areas to do stuff in and move between.

Some of the models uploaded shown below. See the Models/Architecture and Prefab/Architecture directories. Also added some decals of 004 and a prefab of the previous monolith 5 model. See decals folder for decals and prefabs folder for prefabs. Also added start-b map to show the prefab in place.

OK....they are actually standard VR assets from the VR starter map.....I might further play with VR and the assets are small so I think I will add them in here. I am on discord too if any easier.

I had a backup (being what I wanted to commit in the first place). It think I have everything back. I think the only thing that might be wrong is Maps/start.map. I had copied my VR test map over it so I could start it easier as the current code overides the usual default behaviour of starting the editor map you are in. If you can make sure you have a copy of the YOUR start map and then get that back in place then hopefully that will be everything back as it was (plus the new models).

ARGH. Changing my git client has lead me to checkin a copy of the repo with a load of test stuff in it I didn't really want to commit. I'll see if I can get rid of it. There's loads of it unfortunately. Suggest nobody pulls the last checkin unless they can get it back in state it was before that. I use git a bit but no expert so not sure I can properly untangle this.