Rick

Does anyone actually use that checkbox? It gets people all the time

How are you doing collision?

I wouldn't think it would be thousands. Although some of those screens look crazy I bet there is at max a hundred or so bullets at a time and depending on how fast they move could get away with splitting cycles on checking them all. 1/2 the bullets this frame, 1/2 the bullets the next frame, rinse and repeat and I bet that would be good enough for performance. Put on top of that any player movement restrictions then perhaps can only limit bounding box collisions to a certain point on the screen (that could move). Say the player can only move on 1/2 of the screen and can't go into the enemies 1/2. No sense in checking those bullets that are on their way to the player 1/2 of the screen. Stuff like that would be good to do at first glance.

How would you do this with visual spherical bullets though? I mean the idea of these games is avoiding those bullets coming at you at a much slower speed than reality. It's really more about collision with the bullet itself. Picking is instant so not sure how you'd do that with this style of game. I wouldn't go the physics route either but maybe bounding box collision checks on bullets? Or does the Collision() callback get called if you move things with the Move() function? I can't recall.

What if instead of the game app reading the map file a separate process that reads the map file sends network commands to the game app informing it what changes it needs to make? That would be cool! Just brainstorming ideas

+1

If I load a prefab of a csg in code and make instances via Instance() function, the textures are all jacked up and not locked. I'm not even rotating them so this is just the normal locking without rotation causing issues.

If I overwrite an existing .tex file that already had a normal map. Then I delete the old normal map and regenerate another normal map from the new tex (but it had the same name as the one I overwrote from the backend filesystem), the normal map always looks like the old tex file.

It's outdated I assume. I believe we've had map updates since June. But yes, good find as I forgot he posted that.

To get the core LE library & shader updates. I assume those come along with these other MyGame script updates? If we could pick and choose when updating between core LE library & shader updates vs MyGame script updates (or both) then that would be great because 99% of the time I don't need MyGame script updates for an existing project. I don't need a fix in my existing project for FPSPlayer.lua because it's most likely I've already fixed it or heavily modified it so I don't need it updated. Or if push comes to shove I can see on the forums what code changed and make the change myself if I want it, but asking that we copy off the base scripts to make our own copies and use those because of the update process works today just seems like a clumsy flow. It's not intuitive and nobody does it and then when they make a change to a script and update their game they come to the forums and ask what happened to their script in which case you explain the update and backup process that happens. It's just a clumsy process.

So your object file just becomes Script.ObjectDescription = "" --string "Object Description" function Script:GetText() return self.ObjectDescription end In the attached FPSPlayer.lua you can search for RLP to find the code I added. There are a few sections and I do begin/end and everything in-between is what I changed. Now only 1 text at a time will display and it'll still go away after so long. FPSPlayer.lua

Attach your player script and I can help modify it to make it work.

I assume you attach this script to all the objects you want to have this in your game? The problem with that is exactly this . I think you really want this text to be displayed from the player script itself. These object scripts should just contain what you want to say, then the picking should happen in the player script, and from the entity picked you get it's script's ObjectDescription variable and store that in your player script and draw that in post render. This way if you click 2 objects the first one will be overwritten with the second because you are storing it in a player script variable. So in other words these object scripts should only contain data and not the functionality of displaying that data. The player script should get the data from these objects via picking them and be responsible for being the 1 central place to display that data on screen. You can get script data from entities you picked via the script variable they would have (if it's not nil) pickedEntity.script.ObjectDescription [edit] If your script needs to do something special and unique then put that in a Use function but the act of displaying text on screen isn't special and unique so your objects probably shouldn't do that. Let the player script do that from the object information, especially if an issue like this can happen with your type of game.

This might help https://www.youtube.com/watch?v=5WmwNyTlbZE Just make sure you aren't in sandbox mode or you'll get an error.

Worked fine for me, but I did notice one of these releases did a reinstall of the Visual Studio run-times.

If one could ONLY dynamically load the changes this could be a lot of benefit for play testing ones designing. Imagine a sequence that needs to happen and being able to change and reset that sequence while keeping all other things equal. That could save time. It's like you're play testing and during the play test you realize something isn't right in a certain area. You tweak it, that gets reloaded, and you test it again in real-time without restarting the game and having to possibly start all over in what you need to do for that sequence. That's pretty powerful.

This would be cool if the map format was open to us. The script could then just look for when the map changes, and then could go inside of it and load just the changes which would be pretty cool. Reloading the entire map is interesting but still has some limitations. If the map is large it'll take a long time and won't save you much. If your game has an entire sequence thing going on it'll start all over with everything. This is cool though and brings it to the forefront of people's mind.

Updating the exe is generally not the annoyances people have been complaining about though. The complaint is generally around the MyGame scripts that get put into every project. When LE C++ stuff gets updated it doesn't cause any issues. So yeah, just have the Lua game exe's in the template folder. That part should be fine.

For sure update the MyGame template project with your changes so new projects get the fixes, but some kind of "blank" project that would only include the bare minimum (shaders and app.lua maybe) would be nice. These project types wouldn't get updates to anything else (for sure LE C++ updates though as those don't break things). That might be nice for the more advanced users who don't want 90% of the MyGame template stuff. A lot of changes are around these MyGame scripts which are nice for beginners but people who aren't using them deal with some annoyances with them. Maybe an option when creating a new project to pick what we want and don't update these at all. We can do it ourselves if we want to. I feel like a middle ground of beginner users vs experienced users would be nice. I don't know, but the current process just seems clumsy.

Do we have any ideas on what can be done with the little annoyances that come with updating a project? I feel like there should be a difference between critical files (maybe shaders) vs MyGame files that aren't so critical. I dislike files that I delete coming back. I dislike files getting overwritten and backed up. There must be something to do to make LE updates 100% annoyance free. I'm always terrified to update my LE project in fear of it breaking my game.

Yeah, I figured it had to be something else because I use that all the time.

You must have seen a lot of devils when you lived in Cali!

No, this is a bug somewhere because in the game I'm working on right now I do the exact same thing and I have Script.camera = nil --entity "Camera" And it works just fine.

Yeah, this shouldn't happen. I never use "" for an entity type. I always use nil. To me I wonder if those entities got screwed up and you had to delete the camera and relink it. I've seen people talk about having to do that before.

Yep, this is my bad. My camera is following a pivot that I move with Move(), but the camera has the curve function on it, so it looks like the pivot isn't stopping instantly but really it's just the camera catching up. Since I have no visual for the pivot it didn't dong on me that was what was going on.