reepblue

Try to use R16 and import it with the terrain editor. Then place your rocks with the vegetation system.

Yeah, I think I will. Keep an eye out for it

Then you build a new one. I can show you how I do my shapes sometime. Shapes without collapsing models for me doesn't produce great results for my purposes.

I mean using the collapse feature in the model editor. It removes all child nodes.

Don't have time to look at this right now but it's worth asking if you yourself created the collision or these are editor generated shapes. Are the models collapsed? I have issues with non-collapsed models myself.

Please do this so I can stop using aabb for triggers. Also ensure physics objects are compliant as they didn't work as intended in LE4.?

Renamed my class GameSpeaker. I think I'm going to remove SetSourceEntity() in favor of a function within my BaseActor class.

J'adore! ?

Good. But now I need to find a new name for my class. ? Maybe you can modify EmitSound to have a parameter so it'll do the copying of the Speaker for you. IDK I recall that "feature" making me upset using Leadwerks as I didn't expect it to auto release my objects

Loading sounds in Leadwerks has always been straight forward. A sound file is loaded from the disk, and with the Source class emits the sound in 3D space. The sound entity also has a play function, but it's only really good for UI sounds. There is also Entity::EmitSound() which will play the sound at the entity's location. (You can also throw in a Source, but it'll auto release the object when it's done.) While this is OK for small games, larger games in which sounds may change might mean you have to open your class, and adjust the sounds accordingly. What if you use the sound in multiple places and you're happy with the volume and pitch settings from an earlier implementation? You could just redefine the source in a different actor, but why should you? A solution I came up with comes from SoundScripts from the Source Engine. With that engine, you had to define each sound as a SoundScript entry. This allowed you to define a sound once, and it allowed for other sound settings such as multiple sounds per entry. I thought this over, and with JSON, we can easily create a similar system for Leadwerks 4 and the new engine. I first started with a dummy script so I can figure out how I wanted the end result to be. { "soundData": { "Error": { "file": "Sound/error.wav", "volume": 1.0, "pitch": 1.0, "range": 0.25 }, "RandomSound": { "files": { "file1": "Sound/Test/tone1.wav", "file2": "Sound/Test/tone2.wav", "file3": "Sound/Test/tone3.wav" }, "volume": 1.0, "pitch": 1.0, "range": 0.25 } } } In this script, we have two sound entries. We have an error sound (Which is suppose to be the fall back sound for an invalid sound entry) and we have a sound entry that holds multiple files. We want a simple, straight forward. entry like "Error" to work, while also supporting something "RandomSound" which can be used for something like footstep sounds. The script is streamed and stored into multiple structs in a std::map at the application start. We use the key for the name, and the value is the struct. typedef struct { std::string files[128]; char filecount; float volume; float pitch; float range; bool loopmode; } sounddata_t; std::map<std::string, sounddata_t> scriptedsounds; Also notice that we don't store any pointers, just information. To do the next bit, I decided to derive off of the engine's Source class and call it "Speaker". The Speaker class allows us to load sounds via the script entry, and support multiple sounds. You create one like this, and you have all the functionalities with the Source as before, but a few differences. // Speaker: auto speaker = CreateSpeaker("RandomSound"); When you use Play() with the speaker class and if the sound entry has a "files" table array, it'll pick a sound at random. You can also use PlayIndex() to play the sound entry in the array. I also added a SetSourceEntity() function which will create a pivot, parent to the target entity. From there, the Play function will always play from the pivot's position. This is a good alternative to Entity::EmitSound(), as you don't need to Copy/Instance the Source before calling the function as that function releases the Source as mentioned earlier. Just play the speaker, and you'll be fine! You can also change the sound entry at anytime by calling SetSoundEntry(const std::string pSoundEntryName); The creation of the Speaker class will start the JSON phrasing. If it has already been done, it will not do it again. Having sounds being loaded and stored like this opens up a lot of possibles. One thing I plan on implementing is a volume modifier which will adjust the volume based on the games volume setting.Right now, it uses the defined volume setting. It's also a part of another system I have in the works.

Here's an old blog post on the billboarding system for vegetation. Everything is automatic, there is no need to make LOD models for your trees/rocks.

To store a pointer globally, you can just do: // in player.h: extern Player* myplayer; // Player.cpp Player* myplayer; void Player::Attach() { // Code.. //...... myplayer = this; } I thought of this, and I think Josh is right, the loop code shouldn't slow anything down. I use a for loop for bullets and it's fine. If it was my game, I'd do something nifty like have the NPC's look for sound sources and react based on their state/volume/etc. This way physics can also alert the npcs. Just make sure to ignore the check if they are already alert/firing at the player. I'm also ridiculous and it might be too much/not needed for your project; but there's an idea.

If this is a single player game, I would make a master player pointer and do the check from the npc themselves with a simple if statement.

Noticed that decals cause a lot of screen grossness on my Windows machine with a AMD RX480. This doesn't seem to be apparent with my Linux box which has a GTX 1050. I'm running Radeon Software Version 19.5.2 as my display driver.

Just make the entity point towards the look position from the camera. This should give you an idea. Might not compile, just presto code. //----------------------------------------------------------------------------- // Purpose: //----------------------------------------------------------------------------- void MyCoolWeapon::Fire() { auto pick = PickInfo() auto p0 = m_pPlayer->GetCamera()->GetPosition() auto p1 = Transform::Point(0,0,999,m_pPlayer->GetCamera(),NULL) auto lookpos = Vec3(0) if entity->GetWorld()->Pick(pick,p0,p1,0,true,Collision:LineOfSight) { lookpos = pick.position; } // Create A Projectile auto i = m_pProjectile->Instance(); i->SetMatrix(m_pPlayer->GetCamera()->GetMatrix()); i->Move(0, 0, 0.25); i->Show(); i->SetKeyValue("starttime", to_string(Time::GetCurrent())); i->Point(lookpos->GetPosition(),2,1,0); m_hBullets.push_back(i); // <-- Your bullet vector to cycle through all the bullets you've fired. } //----------------------------------------------------------------------------- // Purpose: //----------------------------------------------------------------------------- void MyCoolWeapon::UpdateWorld() { if (m_hBullets.size() > 0) { for (auto& b : m_hBullets) { if (b != NULL) { auto pickinfo = PickInfo(); auto pos = b->GetPosition(true); auto forward = Transform::Point(0, 0, PROJECTILE_SPEED / 60.0 * Time::GetSpeed(), b, NULL); auto result = b->world->Pick(pos, forward, pickinfo, 0, true, Collision::LineOfSight); if (b->Hidden() == false) { if (result) { b->Release(); b = NULL; } } else { m_hBullets.erase(std::remove(m_hBullets.begin(), m_hBullets.end(), b), m_hBullets.end()); } } } }

So, what about the 3D sprites? What would they be called? Billboards? Overall, this seems much more easier to understand. With SVGs, we can now have round HUD elements without fears of rasterization!

I had a similar issue once. I even thought of I used the engines stream functions, it would allow me to access my files within the zip files, but nope. You could try to rename the file as a Lua file and phrase it as a standard text file. I did something like this in Luawerks. Josh, hopefully you are thinking about this when it comes to the new engine. I'm sure people would want to package file formats that they are using with the new plugin feature.

@Josh Please add EFX to the list for Turbo.. :B

Yep, always happens. You have to click off the viewpoint/another viewport to stop the camera.

You can pharse the output stream with C++.

While I think we should have less tutorials, example content is a must. I myself learn things by looking at examples, and then modifying those samples to make it do what I want it to do. Samples should both be freely available and on the market place. We should also have a tutorial on the editor, and where everything is/what it does. But otherwise I agree; no "How to make an FPS shooter" this time. Give them a template and let them be creative. ?

Canonical back tracked on that decision due to the concerns, everything is going to be fine for now. The new engine will be 64 bit and you can always sell your game on other distributions.

Make this another property in the json file so it can be toggled. ?

I recall doing a similar test myself and I don't remember lights without shadows decreasing performance.

Do these models have bones? If so, might be a reason why. We had a lot of people had issues with models with a full body rig.