reepblue

Assigning an actor to an entity during or after level load causes crashing. CPP: #pragma once #include "ActorFactory.h" /* #include #include #include */ #include "../../Game/SimpleActor.h" namespace Leadwerks { void ActorFactory::AssignEntityToActor(Entity* entity, string actorname) { if (actorname == "actor_test") { SimpleActor* a = new SimpleActor; if (entity != NULL) { entity->SetActor(a); } } } /* Actor* TestCreate(vector parameters) { Actor* b = new Actor; return b; } */ } Header: #pragma once #include "Leadwerks.h" namespace Leadwerks { class Actor; class Entity; class ActorFactory : public Object//lua { public: //static void AssignNameToActor(string pName, Actor* actorclass); static void AssignEntityToActor(Entity* entity, string actorname);//lua private: ActorFactory() {}; ~ActorFactory() {}; }; } What I was trying to do was a system in which I'd register all my actors to a map, but this simple function is causing issues...

Wow, looks really great. It feels very fresh, and makes the engine itself more updated somehow. Probably cause the old site just made a list while this gives you screenshots/pictures of what the engine is capable of!

Splendid. Came back here for my Base Actor Class for a C++ player. I'll let you know how it works out!

Make an invisible ramp over the stairs.

Say hello to new set! Higher poly, and way better UV maps than my old models.

Yeah, I missed that post, Thanks Mac!

I agree, only thing I recommend is a way so new games can easily get discovered.

You make roughs like me!

That was most likely the intended purpose, but I can think of a few cases in which an artist might want to bring a brush (or a set of them) into their model editor. Depends on what you're trying to do really.

Unless they are desperate, nobody is gonna want to do that. I was hoping I could just make a batch that converts the vmf to obj. Really odd that editor's obj export doesn't export the uvs in the first place..

My goal was to use propper but since it's a modified version of vbsp, it needs the Source Engine binaries to work and will not build a obj unless you have your textures as a vmt in a source project. It's a lot of work for a simple thing, but do-able. Here's propper's source code. Maybe some one here can make it a standalone app?

Very Cool. I was thinking about UV map exporting to obj, and I think you can by exporting it as a vmf and using propper to convert it to an obj. I'll check it out tonight.

Thanks, I'll give this a try. With my current setup, the local and global rotation values are different so I wanna see if your settings help with that.

Just want to point out that you don't need to join the beta branch to get the updated VC redistributable.

This class is actually based off my beam script, but much simpler. This is written in C++, and all it does is stretch and orient the sprite to two points. You can use this class to make lasers like in Portal 2, simple elevator cables or physic ropes with a script. This just makes it so you don't have to do the setup and math each time. Since the beam is derived from the Sprite Class, everything when it comes to loading a material, releasing and such; that's inherited from the base entity/object class. All I really did was did the math in the Draw call.

This was a quick test, and it worked first try. This is a Beam class derived from the Sprite class. All the beam really is is a sprite that streaches from one point to another. Use Josh's tolua++ generator to expose it. The only way to create a beam is with something like this: Script.EndPoint = nil --Entity function Script:Start() self.beam = Beam:Create() self.beam:SetStartPoint(self.entity) self.beam:SetEndPoint(self.EndPoint) self.beam:SetMaterial(self.entity:GetMaterial()) end le_beam_class.zip

My friend uses it for texturing. I recall him telling me that the newer version(s) allow AO baking and such so it's still handy.

Thank you so much!

It seems that the lighting performance update while is really great in game, has a major draw back in the editor. If you have lighting quality on medium or low and add a static prop, then delete or change it's shadow mode, you'll see the prop's shadow remains until you force a new lighting calculation by hiding/un-hiding the light, or changing the light setting in the editor's properties. Again, everything is working as expected, it's just odd to not have auto updating in the editor with static shadows. Maybe make it so that it uses the older update method if the engine is in the editor?

I agree. The Scene Tree is just a mess and I actually don't like using it when I have to parent 2 entities together when the list is really long. I might also suggest a Parent drop down in the General tab that'll auto adjust it's position in the scene tree.

I noticed that in newly created projects, C+11 isn't ticked for Code::Blocks.

Oh no, another problem with env probes.

if it's 0.05 seconds long, I don't think it'll will not kill you to leave it as a wav.

As long as the stock code after creating a new project is still set up to run the main script, I'm fine with the App Class going. Like Evar, I usually delete it anyway,

Yeah the editor hit's it's wall when/if the user decides they wants to use C++ for their entire game.