mdgunn
-
Posts
626 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Posts posted by mdgunn
-
-
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.
-
2
-
-
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.
-
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.
-
1 minute ago, aiaf said:
No, something like a bottom part of a star trek teleport on the ground. And a tech device near that circle extruded from ground.
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'.
-
On 12/6/2018 at 8:39 AM, aiaf said:
gate model
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.
-
3
-
-
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.
-
1
-
-
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.
-
3
-
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.
-
1 hour ago, aiaf said:
I just want to rotate the camera say 90 degree on y axis.Any ideas?
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.
-
9 hours ago, aiaf said:
How can i access this camera from another script ?
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
-
9 hours ago, aiaf said:
Im not used to this le scripts.So have quick question.
In fps player script local camera is created:
self.camera = Camera:Create()
How can i access this camera from another script ? I want to se the position from another script.
Is it any way or i should create a global camera.
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' .
QuotePlayer given reason to escape to surface, perhaps to escape growing number of incoming spheres. A short series of corridors and rooms eventually leads player up to airlock.
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.
).
Added Models
in General Discussion
Posted
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.