mdgunn

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!

I have some big problems with Leadwerks crashing at the minute and currently can't even save the cryo room. Just Get some sort of fatal exception. It seems to be happening in other projects so not too sure what is going on. It's made me rethink converting some geometry to normal maps so that the map scene graphs are not so full of simple objects. I will do a few more I think, partly to practice the process. I may need to do a rebuild of the cryo room if that is what it takes to stop the crashing. I don't trust just stepping back to an apparently working version. I've seen some similar things before where if you work on a map for a long while it seems to encounter problems. The shot below is just 3 CSG brushes now. I'll see if I can do an update later on where I see things being at as we push forwards to an end point.

Ultimately I don't think we want the weapon like this so this is just minimal work to make it less like a pistol for now. Testing the muzzle flash in the darker area.

I was keen to get waypoints in as they give us some interesting options for AI behaviour just the basic charge and attack which I find can get boring fast. I'd like to take things a little further so we have some interesting behviours that the user can play with to their advantage . The small half-cubes on the ground are debugging shapes to help see the target picking of the waypoints. First attempt may need to continue to refine. Based on The Hankinator's extended MonsterAI script

health and potion/energy prefabs now have working scripts which will supply heath and energy to player. Just thought, may need limiting to prevent AI trying to pickup or crash script if they do. healthstation can deliver single large charge. Could be made more complex later to deliver a slow increment of health over a period of time.

I linked the credits into the menu system but I have never really messed with the GUI system (just used clickable images and key presses usually) so it is certainly possible that it isn't completely integrated as it finally should be. Possible I broke something too I suppose but it seems OK. You could argue that there could be a GUI button instead of hitting esc (which was just a quick fix), but then typically I think the background is usually grey when we want it to be clear on credits. I'm sure there are ways to address this if you fiddle enough but the aim was merely to integrate in some basic way so if someone has a better vision fits best with the existing setup they can make it work as a whole.

I suppose we could do a level change for this. I was also considering if maybe we could move between little isolated scenes within a single simple map when major menu items are selected e.g. new game.-> OK(selected) - zooms you to the start of the planet crash cinematic. continue -> zooms you to planet surface with fade out . Basically similar to start cinematic but no cube there. goes straight to planet swoop and fade.. settings -> starts the normal menu system - Maybe it zooms to a moon first and then options appear overlaying that. credits - zooms you to the title sequence scene. This may all seem like a lot of extra work but I think it would give a better initial impression of the game and I think for the amount of work it might be good payback. I'm not sure if there are difficulties I've not thought of. I'll not pursue this just yet but personally I think it would be neat to have something less static that just dropping into menu with static backdrop.

Well I've not really quite figured out who did what but in general I've been avoiding touching other people's stuff and picking up things that were more on bits I was doing before. I think there are a few player combat things that I wasn't sure were things were up to, or I've been told might not be 100% working . E.g. the plasma ball. I've not tried to fix it. In general there's a good chance I've probably got my own code from some other project for any particular thing so I'd maybe just drop that in but in general I'm working out from what I was doing previously.

Cinematic tests. Cube crashes to planet surface Cube burns/descends through ground to outside cryo room Project Forth: Fade and Cut Test Testing fade out and cutting to alternate camera/view. Fade not fully complete yet.

Very simple scene for title scrolling which can easily be added to without any need to fiddle with code. Just got the same placeholder repeated for now. We'd need to consider what we want the actual content should be, and if we need to mention any open source assets. Need a way to get to and back from this scene. just in place as a test scene in the test folder of maps...

I hope you don't mind but I have started to refresh the Trello board (https://trello.com/b/RsYy7AbK/forth) so it can be of some use on tracking things to an initial release. I will continue to refine a bit more. The main aim is to make it a bit cleaner and simpler to see what work is proposed for the first release, what is in progress or done, and what we are not planning to tackle yet (PROPOSED) . I would suggest we keep cards fairly broad in subject (e.g. enemy AI) and use a checklist called tasks in each card and keep the number of cards smaller rather than lots of small cards that may be on similar thing. One problem with this proposed way is that with only a few cards and task lists it may be less clear who is working on what, especially if we are working on what. The best way around this might be that we try to focus on different areas of work, or alternatively a check list item can be popped out to an individual task when underway. There are MANY MANY ways to do Trello and I vary sometimes myself but if you agree maybe this will keep it clearer what is outstanding and what is left to do from the checklist items. I have archived a number of items which are fairly old now in favour of having a board more reflective of current intended work.

I will consider how to get some minimal fun behaviours into a first cut of combat and consider your suggestions along with what I have in mind as a backlog of intended first things to complete. I have always found the cryo room a little confusing (sorrt) as I've mentioned. In principle there's some interesting deep mechanics but I strongly thing that it should be phased in some way so that on first encounter it's is visually easy to determine what is needed if possible even without any reading. This might be possible. I think you are OK with me tweaking the look of the room (maybe those missing blocks or some simple architecture?). Let me know if you want me to do or not do certain things. In the same vein if you would prefer I put in place mechanics in the cryo room let me know. Maybe you feel it works best if I model and you script. I think I probably do need to get back to scripting in the cryo room , particularly with cinematic elements with the initial room entry and the enemy ball thing. I may look at scripting out the other things such as health station, doors, lights (alarm state and normal state) and other things. We may need to discuss about remaining scripting. If you have limited time and want to focus on your other project and do only bits on this one fine too.

I've returned to some AI combat work. Personally I find this sort of thing takes a long time to iron out what with all the animations and debugging scripts. I've gone back to basics and worked at getting the basic monster ai (MELEE AI) and soldier ai (FIRING AI) working with a couple of test models. IMHO this is a good starting point from which to build. Stock sound effects and visual effects. Long way to go but there's some satisfaction in surviving and taking down enemies.

Overhead lights and walkway edge light use palette entries set to use emission. The ceiling ones look less strange now as they don't seem so dull as if not emitting light. Tried to reduce the number of lights and use more 'ambient' light with a non-shadow casting point light. Speed still seems to be taking a hit and I think it's still the lights so will need to experiment some more.

First go at health station. May redo a bit with lower poly. Forgot to reduce the geometry on the cylinders I was using.

In an attempt to narrow down the problem with more data....have you tried images generated by others (preferably more than one source) and what were the results? Have you tried saving to different formats or from different software for the final image? Perhaps try saving out a working one from the software you save normal images and see if it breaks or continues to work.

Flying objects is the reason Forth is not moving to 4.6 right now. Good to know it's getting attention. Thanks!

OK thanks for the info that should help a lot.

Just to add....I am fine just having a simple hand blaster weapon which is present in the repo already. This may have seemed weird (a strange thing embedded in a hand) but the main thing was that it was simple and most importantly....done. For the story it was going to fit in something like this....the red light ship activating enemy that merges with the character when it explodes as she stops it taking over the ship in the second room (if I remember what I intended correctly). Don't get me wrong I am happy to have have modeled the gun. For times sake I think it would still be better to keep with a literal 'hand blaster' and when we have everything done and have a satisfying game then we replace some things. To me weapon modelling, firing animations, reload animationss, 3d arms animations etc etc. is a potentially large time sink which in our position is probably best to bypass as much as possible. Also originally I think we were aiming for something more of a mystical environment where things might be more 'magical' possibly in a future fantasy way, than space marines and bug hunts (yawn). The cyro room is now fairly strongly typical sci-fi. More than I had in mind really. My original idea was to try to combat to a small combat arena (like player is trapped in spell/force field) probably encouraging melee combat and limit these 'arena spawns' to some key trigger points. This was we have better control over combat and issues such as enemies not handling terrain well, player taking advantage in AI limitations etc. I will see where we are at with the mine and others weapons code and see if I can figure out where to go. I may integrate the gun but getting what we have already into better shape may be the priority.