Inactive Miniion
- Thread starter overdhose
- Start date
no worries, we'll shuffle some things around once we move to another blog anyway I guess and give it all a bit more structure. Given the current layout it's best not to clutter things, so keeping it together makes sense for now. Ain't gonna blame you for showing interest in some bad coding heh.
On another note, I don't know if anyone can provide me with an answer on this, but I'm trying to figure out block positioning in the world and how to position entities at the middle of them every time. I'm guessing that currently, unless I'm wrong, a block's position is determined by it's corner, as in a vector actually points at a corner of a block, and not it's center. From a pure path finding perspective, I was wondering if it wouldn't make more sense to have the positioning point to the center of a block, and if this would impact other things in the world like building etc.
From a performance viewpoint, I think it would make more sense, as you wouldn't create an overhead (I think at least, so correct me if I'm wrong) trying to determine from which side an entity approaches a block and position it in the middle of it. Actually, the position of the entity itself in the world, is it determined by it's virtual middle point?
I might sound lazy asking things like this, but it's still pretty hard for me to determine things like this just from looking at the code. Just trying to get my bearings here to know what direction I need to look in to solve some issues I'm trying to get solved. Hints and tips as always welcome and much appreciated.
On another note, I don't know if anyone can provide me with an answer on this, but I'm trying to figure out block positioning in the world and how to position entities at the middle of them every time. I'm guessing that currently, unless I'm wrong, a block's position is determined by it's corner, as in a vector actually points at a corner of a block, and not it's center. From a pure path finding perspective, I was wondering if it wouldn't make more sense to have the positioning point to the center of a block, and if this would impact other things in the world like building etc.
From a performance viewpoint, I think it would make more sense, as you wouldn't create an overhead (I think at least, so correct me if I'm wrong) trying to determine from which side an entity approaches a block and position it in the middle of it. Actually, the position of the entity itself in the world, is it determined by it's virtual middle point?
I might sound lazy asking things like this, but it's still pretty hard for me to determine things like this just from looking at the code. Just trying to get my bearings here to know what direction I need to look in to solve some issues I'm trying to get solved. Hints and tips as always welcome and much appreciated.
I think the key issue here is that there are two different Vectors at play - a Vector3i that's integer based and maps to one specific corner of a 3D block, and a Vector3f (or d? I forget if a float or Double) that records exact position for things like entities. I suspect for pathing you'd want to by convention turn a Vector3i coordinate into a Vector3f centered in the middle of said cube (by adding 0.5, 0.5, 0.5 or what not) and purely deal with float (or double) math
I think we need the Vector3i based at the corner to properly render textures, while the Vector3f is much more useful for gameplay.
Take this with a grain of salt as I'm mostly making it up as I go along based on vague memories of looking at that code some time ago...
I think we need the Vector3i based at the corner to properly render textures, while the Vector3f is much more useful for gameplay.
Take this with a grain of salt as I'm mostly making it up as I go along based on vague memories of looking at that code some time ago...
My main issue at this point is the minion standing at the edge of a +1y elevated block at a certian float based position and certain rotation. what position does it actually return, the block it stands on or the block it's half floating over? Does it return it's position the the virtual vlock space it takes in, or does it return the the adress of the block it's standing on? Let's say you have a field, and only 1 block sticking out at +1y (height) and I click that block, I want the minion to go stand on that specific block, but unless I'm doing something wrong feeding it a destination that's actually Vector.add(0.5f) on an integer based value, doesn't actually center the minion as close to the center as i expected it would. And looking at the code to get the worldposition of an entity didn't make it any clearer to me as to how I can make sure vectors from a block correspond to vectors of an entity.
The position of the entity is the center of its collision area, so it is the height extent of the collider over a block. And blocks are centered on their coords, so the entity would be another 0.5 above that, due to the block's extent. (This is observable using the F3 stats and the player's position)
This would mean to stand over the block at, say, (5, 6, -2), you'ld want to send the minion to (5, 6.5f + x, -2), where x is the height extent (half height) of the minion. The height extent is modified by the scale of the minion if any.
This would mean to stand over the block at, say, (5, 6, -2), you'ld want to send the minion to (5, 6.5f + x, -2), where x is the height extent (half height) of the minion. The height extent is modified by the scale of the minion if any.
suggestion for forum thread : would be nice to have a miniions wip mod (or whatyouwonnacallit) thread and a miniion:feedback thread if at all possible. It would be nice to have 1 thread to ask (technical/programming?) questions that can be answered by people who don't wonna read all other posts related to a topic, like suggestions etc. If you are busy with something even more elaborate then feel free to ignore this.
Forum categories have been shuffled around a bunch. We should probably split this into a general creature / minion design thread and your implementation over in the shiny new Design & Implementation forum since both are pretty solid
well actually you mentioning this, I started thinking, also because I had made steps myself to incorporate miniions as a full fledged mod. I remember Immortius stating he'd like to see a thing like miniions become a full fledged mod on irc at some point (well I believe it was immortius and/or IronChef) and I had done some thinking about it. I know the way some things are done now it's not really a "mod" anymore, specially thinking about modifications to the bullet physics class modifications I made to have miniions gather loot. On the other hand, as the thing grows it might make a great example as a mod, besides the fact I never created any miniions events which I planned to incorporate. So I was thinking now : it might make sense to keep some miniions mod alive in which I continue adding things and whatever seems usefull can be added to the core, after reviewing / cleaning / accepting as core. That way I could keep tinkering without having to worry about it being "good enough" to be integrated. For example, I wanted to create a minion command stick which I wanted to use to select areas for gathering / leveling and building, but the stick itself might become a general blue print tool at some point, so the miniions:commandstick could remain a placeholder untill a better option becomes available. The selection code behind it might be usefull later. As far as selection is concerned, I would really like to give visual feedback to the user about selecting an area, it's a feature I'd like to request as it would be an important part of the game if you ask me.
another thing I wanted to request : a block ID for a patrol block. just wanted to create a simple block with a flag texture to use as a sort of minion event block. For example clicking it might instruct a minion to start gathering the selected area attached to it. Just wanted to check what my best option was at this point : wait a bit for more block ID's in the form of a mod, or reserve an ID for testing, or even reusing a chest for example for the time being.
Huh, just realized I haven't spotted how to quote somebody yet
On blocks - you don't actually reserve an ID, you just make the block definition and it gets assigned one. You'll want a flag textured block with a prefab setting of "waypoint" or so, which doesn't exist yet but has a request issue and everything - https://github.com/MovingBlocks/Terasology/issues/75
I wouldn't suggest holding back re: the mod issue - just go nuts and we'll integrate what makes sense to core content in whatever shape that takes + externalize anything extra as an optional mod when that system is fully ready
Multiblock graphical selection is definitely on the short-list, we used to have something like that in the old blueprint code (copy paste terrain tool)
On blocks - you don't actually reserve an ID, you just make the block definition and it gets assigned one. You'll want a flag textured block with a prefab setting of "waypoint" or so, which doesn't exist yet but has a request issue and everything - https://github.com/MovingBlocks/Terasology/issues/75
I wouldn't suggest holding back re: the mod issue - just go nuts and we'll integrate what makes sense to core content in whatever shape that takes + externalize anything extra as an optional mod when that system is fully ready
Multiblock graphical selection is definitely on the short-list, we used to have something like that in the old blueprint code (copy paste terrain tool)
What I meant by this, since we don't have code support in mods (or modules or whatever we want to call them) yet, is simply moving the prefabs/textures/sounds/whatever that miniions uses into a separate mod structure like the "core" mod/module.
At the moment the engine is still somewhat underbaked for supporting changes as pure mods - the physics and camera haven't properly been integrated with the entity system for instance.
On block ids, they should basically be invisible most of the time, and some of the world refactoring I'm doing at the moment helps to achieve this by not exposing them to the user. You just create a block definition, and get it out of the BlockManager by name. Don't even really need a waypoint flag, can just check it by name.
well I started moving in that direction now, so from your comment if I move my own components etc (excluding bullet physics for example atm) into a mod folder in terasology, that would pretty much conclude the exercise at this point, leaving things like the bullet physics as is untill better solutions are available. The available things (like prefabs) I actually started shuffling around, so here's your first point for always answering the topic as spotless as always...
and Cerv you promoting DF so much I grabbed it and trying my first session to get some inspiration hehe
and Cerv you promoting DF so much I grabbed it and trying my first session to get some inspiration hehe
read your idea to have cubes climb up walls and ambush players... pretty neat, will try to come up with something if I have some inspiration.
I have actually been pondering, playing DF a little, how viable some of our crazy ideas are. I don't know how optimized it all is, but seeing how resource hungry that game already is without the whole 3D rendering/ pathfinding etc... well I ain't no expert in those fields, but it makes me ponder... maybe my beast here (athlon 5500+) is getting to old.
I have actually been pondering, playing DF a little, how viable some of our crazy ideas are. I don't know how optimized it all is, but seeing how resource hungry that game already is without the whole 3D rendering/ pathfinding etc... well I ain't no expert in those fields, but it makes me ponder... maybe my beast here (athlon 5500+) is getting to old.
The thing about DF is that it has been put together by one guy in pieces over six years and is closed source...
Building for a comparable scale but from the ground up with a larger team and a focus on performance and server-based multiplayer with everything open source I'd like to think we have a good chance to pull it off. Especially by heavily compartmentalizing features you can turn on and off. Maybe you'd need a pretty beefy server to run with everything enabled, and a beefy client to display everything, but if you had less snazzy hardware available you could always disable some fanciness.
On the server side I'd like to keep on top of thoroughly using multi-threading where able, and even multi-node capability for really solid worlds. Oh Project DarkStar / Red Dwarf Server why did Oracle have to kill you
Building for a comparable scale but from the ground up with a larger team and a focus on performance and server-based multiplayer with everything open source I'd like to think we have a good chance to pull it off. Especially by heavily compartmentalizing features you can turn on and off. Maybe you'd need a pretty beefy server to run with everything enabled, and a beefy client to display everything, but if you had less snazzy hardware available you could always disable some fanciness.
On the server side I'd like to keep on top of thoroughly using multi-threading where able, and even multi-node capability for really solid worlds. Oh Project DarkStar / Red Dwarf Server why did Oracle have to kill you