mdgunn

Got the models (first set) pushed. It seemed to think there were more changes than I had actually done. I think leadwerks can tend to do this. Hopefully repo is OK if not let me know.

Sorry still slightly confused. The thing you described sounds like a teleporter and control panel for it. So what is the gate?

Tried pushing to repo. Got a login problem, might need to reset password. Got to go out for a bit, will sort upload later and also do more models for 'dream room'.

Was gate model same as teleport pad?

Should be able to upload the models later today. They will be very prototype in nature...probably no textures or even physics. This just to test out a style. May completely scrap them all so don't want to wast time re-texturing, UV-ing, importing again etc. Not planning to make the game VR (thought we could make have an explore mode where you can just visit the maps in VR and maybe trigger dev notes or something? Mainly did it just because I thought it would be interesting to be WITHIN the models I'd put together.

Got a Lenovo Explorer mixed reality headset in the Black Friday sales so feel compelled to see what the Cryo room I've thrown together looks like in VR.

OK thanks

Are you thinking this area would be similar to the rest of the ship and so sci-fi in style. Some of these objects sound a bit non-sci-fi, which is fine - just trying to know what to go for.. Just wondering with the book on pedestal. Would they still have books, maybe this is an old book artifact?

OK.... I will get look at throwing together some quick low poly models (mostly grey but maybe with some colour accents) as follow: terminal/screen to put on Wall. small tablet large table (possible integrated screen) small table monolith with '004' on. simple couch (surely people sit down in space ships right) simple stool cyro pod storage crate small cupboard locker All items will initially be dumb (e.g. the screen isn't going to be setup to allow an image at this point). I don't expect they will be great either. I will just spend a few mins on each probably. Also....in the mean time consider that any object can be mocked up as CSG prefab with pivots and using this method when the model is dropped into the prefab and the CSG removed from prefab then all COPIES of the prefab that had CSG will get the model in the updated prefab. At the minute a lack of a model should not really prevent progress with mechanics. I will set a loose target of tomorrow night to get all the items listed above done. May not be possible, we'll see. If there are any others add them in though as if I get on a roll then I might be able to get a good set done. I will add them to Trello later I think. Going too far with models could be a big mistake if we try don't use CSG as a first proving stage. On the other hand I think I would like to see a single room (even if it was not actually in the game) that represents the look of what the inside of the ship would be like. This would then be useful to monitor performance of a full room with lighting etc. Such a room should not be the same room that we are trying to make a playable level at this early stage as it becomes a big time loss loading up the more complex room. Could be a COPY of a planned room but preferably not the room you load up to develop against. I will look into this test room, probably based on the cryo room. I will probably use it as somewhere to test stage props. Will see how far I get by tomorrow night. I will try to upload what I have then. I'll try and do the ones you mentioned first aiaf but if there are objects that are similar I may do those so I can reuse an existing mesh etc.

You might want to use this as the basis for a texture.

Haven't had much time this week but I'm planning to assemble a few props in the cryo room which would probably overlap with what you mentioned. E.g. -terminal to put on Wall -small tablet -a table model Plus others. Take care getting sucked into model and texture details at this point.

I will consider blocking out the cryo room. The things I expect in the room will be something like this (not fixed - but ideas at the minute): 4 cryo storage caskets (1 open/deployed, others embedded in wall still) (labelled 001, 002, 003, 004 - 004 deployed) 4 lockers (labelled 001, 002, 003, 004) wall mounted display showing picture suggesting arc of incoming activation sphere (wakes up the non-staff cryo war faction humanoids if it enters ship and completes it's activation). Viewing window in raised area at end of room (can see falling meteor spheres from here and also escape ship with flashing light to draw attention - I think maybe this should be early goal to reach this ship but by having to go long way via surface exit and back down via other route, or edge of island/ship). Ceiling mounted tube to deliver incoming sphere as part of leading on to next room. Info table/computer has some further images showing more info such as alarm in progress or maybe button to turn it off. Locker 004 contains tablet computer for finding out backstory and first mission steps. Blocked something out in Blender (just to test the 2.8 beta). Will return to Leadwerks for further blocking out I expect.

Good work. Not sure how common it is to replace many objects with vertex colour. There may be down-sides in a fully populated world. It is something we can experiment with. What sort of poly count do these objects have? My best guess is that the optimal approach would be to use the low_poly_palette (in the Material/Simple directory) to colour object faces and keep poly counts as low as possible and not increase them to capture colour too much. By using low_poly_pallete on as many objects as possible reduces texture usage to almost zero and keeps speed high by sharing the same texture between many/all objects and having quite simplistic UV mapping (basically move faces to the colour you want them to have). Another benefit of low_poly_pallete is that if you want to switch colour shades you can do this for your entire world just by updating one texture (say you wanted a less or more saturated look to everything). (You could do this with a post-process filter of course but with a low poly palette you can individually tweak around with specific mapped colours). For terrains the gentle flow of colours that you get of vertex colouring is probably a desirable trait, whereas on objects you nay want a more defined boundary to colour changes. Terrains are probably a best case scenario for the advantages of vertex colour .....as long as the look of it is OK with the environment we aim for. For objects I suspect that objects may have higher poly count than we would want if we pursue vertex colour too far but these props will help us investigate this further.

If you want to rotate a camera then you need to consider what is rotating around. I mean do you want to turn/pan the camera from it's current point, or rotate it from a distance around some other point. If it's the second one then you would usually use a pivot as a child of the object and have the pivot at the point you want to rotate around. With the FPS controller I think it can be a bit tricky as I THINK it sets the rotation quite late in the script and probably wipes out what you may have setup earlier. This is quite common in games....to first gather up a number of criteria on things that might affect movement and then finally apply what the end result is towards the end. If you are finding cameras and controllers tricky I suggest taking a look at both the spectator cam script (where things are a bit simpler) and create the marble game project and check the camera there, which again is simpler and you can easier test how you think things should work without worrying about things like mouse smoothing and camera smoothing that are probably affecting things in the FPS script. Need any more help just ask....the standard LW forums also have some answers on these issues I think so may have more info than I am giving here, though it can take time to locate, in which case just pop back.

You can access a variable in any script usually by getting a reference to the object then it's script then the property or function like this. item.script.myproperty = "newvalue" item.script:MyFunction("newvalue") So how do you get a reference to the object in the first place you might ask. Well you CAN scan the list of possible objects in the whole world and try to match something up (like a 'type' or 'name' property you've created in the script), but this is usually a bad idea. Usually it is best to setup these references in the editor or via interactions with objects via collisions etc. If you do access an object it is usually best to TEST the presence of the thing you expect to exist otherwise something unexpected might trigger firing instead. For example in a teleporter you might test if a property on an enemy or player, but what happens if someone drops an prop in the teleporter and that prop does NOT have the property you have on the players and enemies. Script crash is what probably happens. Here is how you can test for a function or a bool (there are other types such as number and string i think). if self.enableInstances and type(item.script["Enable"])=="function" then item.script:Enable() end if self.enableInstances and type(item.script["timeOwnDeath"])=="boolean" then item.script.timeOwnDeath = not self.destroyChildren end

It is reasonable to pass in a camera as well. Not sure I would make it global. If you have something like Script.camera=nil --entity "Camera" then you can set this via dropping a camera from the editor onto this form element in the properties bit and at runtime the editor camera will be set to be the one you dropped on the element. You could also set a camera programatically created elsewhere onto this same variable. I think all Script.<PROPERTY> things are accessible everywhere, though only when the object the object exists as an instance you have setup in the editor or programatically created from a prefab or by attaching the script to the model. This probably sounds complex but it's not that really.

I did start doing some CSG of some rooms (I think they are still on my laptop). If you prefer to focus on simple square rooms and the actual mechanics of viewing simple doc and teleport and traps etc. then I don't mind fleshing out the rooms (I think - could well be a lot of work ). If you focus on mechanics always remember that workshop often has example of something similar. We may well implement our own but they can be good starting point for basic concept. For example there is a 'view note' item....forget the actual name. But even if you know how you would do it I think I would probably compare against a workshop item if it exists for any planned items. Also remember I added a teleporter add-on in the source and I believe I also added a simple switch and a simple timed trigger I think...check the addons folder. If you need help locating or understanding them let me know. May well not use them but if it saves a few minutes initially then consider using them. WARNING: I would warn against bringing in any worksop items into OUR source. I would say bring them into a separate project and examine them there. Some addons will scatter their contents into your project and after many items you may not know what belongs to what. This is why I have created an addon directory and tried to add generic stuff out there where it is clearly separate. IMPORTANT NOTE: When doing rooms please try to keep to POWER OF 2 sizes, or POWER OF 2 FRIENDLY sizes . If unsure what this means I mean that a floor should be 512 x 512 or 1024 by 1024 or 512 x 1024 or 256 x 2048. This way things will more easily fit together. Once we get moving a bit the levels may well need to break out of this and become more organic and interesting in and have more varied sizes but initially can we try to keep to FRIENDLY POWER OF 2 so that we have better chance of fitting things together? Thanks!

Ok great. Seems to fit fine into the very loose suggestion I put in the doc in the 'Fight to Caves' . I didn't emphasize exploration and puzzling but in my mind I am VERY MUCH OK with this and would probably be my assumed direction with the game when not in combat which I think could well be most of the time. I think puzzles and exploration type game is VERY achievable in Leadwerks. Would be fine to not even have a fight. Fight was just one possible idea as an opportunity to have combat tutorial. I think originally I imagined that the bulk of information gathering might be at the village but that was more when I saw the hero as probably being a villager or native caught up in this, whereas in the end I went with her being part of this long buried race. Now, it probably makes more sense for this information gathering to happen before existing the ship as you are suggesting, Some additional backstory bits could still be in village (if we have one). If you want models then try to give me some clear info and detail on each one (if possible) so I can determine which order to do (though ultimately I will probably do them in order I see most fun in to help me keep engaged). Maybe add them on the Trello board I guess. Of course I know you will not expect me to go crazy and deliver loads of models so I think we will both understand there will be a balance of what I can deliver and it will initially probably be very basic and rough.

Had a bit of a break after doc to refresh my mind. Ready to move forward again. I think if each person tries to construct a simple area with some simple mechanic and hopefully someway in which they can see it fitting loosely within the concepts in the doc then that would be a step forward. Something like this where I was testing out AI navigation and combat. This arena is about 3000 x 3000. Sounds like aiaf has a plan for a few levels. We still need to get combat finished (weapon ammo/pickups, shooting/attacking, taking hits, weapon inventory ammo counts etc). I can do that unless someone else feels they can do it. I'm happy to pass it over if someone else feels strongly about it. The other area I would like to finalise a bit further is a basic island/spacecraft. All the islands don't have to be spacecraft (could maybe just contain some tech power source). I think it will still be tricky to have both an island worth moving about on, and a spacecraft that looks good all in one (compared to just a floating rocky island) but I think I will still have a go. I suppose those are my 2 main areas that could be finished off. I in general I am also thinking generally about level creation and model creation and how we can try and make sure they look like they go together rather than looking like a strange Frankenstein's monster of different assets. Thirsty Panther what area do you think you would most be able or like to tackle first from this point? Could be mechanic focused or level/area focused or some balance of both.

Personally I'd probably let him know, though I'm not sure there's a clear way to replace. There were recent changes in model imports being discussed, relating to some new more portable format gltf or something (probably got that wrong). Not sure if those changes are actually on the standard release. I'd expect them to be on the beta branch but not sure. Anyway, you could be you're getting hit by a legitimate but rare bug only recently introduced and may be easier to locate and fix when Josh has recently been in this area.

Hmm I was going to suggest it could be related to the specs of the 940MX but it looks like it suggests OpenGL 4.5 so I think that should be fine. I have run Leadwerks on a few mobile chipsets and was fine too. Not too sure about causes yet. Would suggest trying a version a few back if you hadn't using beta tab. If it happened to work without problem then Josh might know what cause might be given changes in between and the type of error here. However given your situation I think I would expect stepping back not to work. Another thing to try is create a project with either or both the Marble Game project and the First-Person Shooter projects. If they both work then Leadwerks is probably mostly working and the issue is limited to just this area of model handling or new models and the scope may be narrow enough that Josh has a good idea about a possible cause and solution for you to test if you contact directly.

Could be something to do with different things on different drives but I have my various bits in different locations. My steamapps with Leadwerks is on D, my user data is on C and my Leadwerks are on various other drives such as E . I know when creating projects in Leadwerks it wants to put them in my User space in My Documents (I think) but I always specify a different folder such as E:\WORK\Leadwerks or whatever on an alternative SSD drive. Doesn't seem to have a problem when I create a project where I specify if you think this may have thrown it out. My Leadwerks.cfg remains in my user space as I think you are saying too. Could be Leadwerks is generating some additional logging information that might help you. It should appear inn User\<USERNAME>\Documents\Leadwerks. It will likely be showing similar information to what you should see in the editor at the bottom but it might have something extra, or be easier to see it all in this log file. Worth persevering a bit more. If have some possible info on the likely cause then and it is something Josh (the software) author can do something about it then it may well get fixed rapidly. It is common that issues that can be reproduced by Josh are fixed pretty much immediately (or it seems that way to me) and are pushed out to the beta branch (available in steam). It would be important that Josh can reproduce of course. If you have some good info I would recommend a direct message to Josh via the forums. BTW: Your test of the blender cube export via FBX is a good one and should have worked. I exported a from Blender all the time. It may be possible to export from Blender from an FBX version that Leadwerks does NOT understand (as one problem with FBX is the various binary and text versions that exist now) but I regularly export form Blender in FBX with the default version it specifies without problem.

Unfortunately this sounds like it might be very specific to your machine (I don't recall anyone with this issue before - but maybe I missed it). I can only suggest things to try and determine if that is indeed to problem and then to try to narrow down what might be the original cause. I personally have imported FBXs all the time over a number of years and different versions of Leadwerks and different computers (laptops and desktops) and I don't recall seeing this issue Try the following: Try a different machine - I know completely unhelpful if you don't have another machine, but if you do give this a try and report back on if the other machine does happen to work You can try an older version of Leadwerks in steam if you go into the beta tab. I suspect this won't fix it but it's quite a quick and easy test.

When doing vertex colours I usually still apply a super simple white material (usually the white one in Material/Simple) . I forget if this is necessary but it may be something you need to do. If you notice the colours freaking out in leadwerks (I've seen them flip colours to a 'negative' version) it is possible to get it back. Usually if you reassign the material or switch to another and back it sorts itself out. May be just a strange temporary editor issue rather than a permanently saved problem with the model material.

I did a video with a navmesh test see end of this post. AI worked fine. Something about the Soldier AI had an issue but the Monster AI was fine. I think up we agreed about 100m, I think it can be higher maybe up to 200m but then I think there will possibly be too much space to wander around in. Size could lead to slow down and we probably need some more tests for this but currently I didn't see it as a problem. I will do some further test though and maybe stick some test files in the repo of the same mesh but at different resolutions and test the slowdown.