Yes, provided I or someone else can tweak it into shape, it will have multiple uses. I'm going to try to devote some time to it today and if anything significant happens, I'll reupload and update here. I really had no plans to work on it after the initial upload, but I changed my mind.

Ok, a new version is uploaded and initial post edited.

Here's what changed:

1. Fixed the grid snap...it now works correctly no matter how far you are zoomed out or the view angle

2. Fixed the rotation bug that Marco described

3. Implemented the ability to: Grid snap in XY direction, snap into X only(by holding down ctrl key), snap into Y only(by holding down alt key), no snapping at all(i.e. smooth movement)

4. Entity can no longer be dragged up a wall if the texture scanned by the mouse_to_level trace is pre-defined as illegal

5. Optimized some code

6. Generalized some values to add flexibility

7. Added some comments to scripts

Ok, I uploaded another one. Not much different, though I altered the demo level a little bit. I also included a readme. The controls have changed a bit, so see the first post or readme for that.

Known issues for anyone wanting to improve it:

1. Grid snap quirk.

a. If an entity is on an elevation and is restricted to movement either in the X or Y direction(by holding down ctrl and alt keys), the entity can fly right off the block and into empty space. It can be released and will hover in midair. This is directly related to the fact that the Z position of the entity remains consistent whenever a restriction is true. I consider this a serious issue. A workaround is to simply disable restricting.

b. When an entities' movement is restricted and it is on the main ground plane, it cannot be placed on an elevated plane. It is very easy to make it do this, however this leads to the entity becoming elevated if the mouse cursor passes over an elevated plane and the entity is nowhere near it. I chose to eliminate placing an entity on an elevated while it is restricted because of this. If this issue can be resolved, then letter a.will also disappear.

c. If snapping is turned off(setting the snap vars to 0), the entity will sink into geometry up to it's origin and will hang off of elevated blocks by the same distance. Not a serious issue if you are using snapping(which is recommended).

2. There's no kind of entity on entity handling or entity managment period

As is, an entity can be dragged on top of another one and released from the mouse cursor. Ideally, if this happens, the entity should not be able to be released and neither should the other be able to be clicked on while the active entity is on top of it. Also, there isn't really any other type of entity management. This is just as serious as the one above.

3. Wobble cam when smoothing is > 0 and you rotate the view

Smoothing is what makes the camera gradually move from one position to another. It works great when you move the player around, but once you start rotating the view(right mouse button), the view will start to wobble. I have no idea how to fix that and the smoothing code is near the bottom of the cam.wdl. Smoothing is always 0, as is, so it is not an issue unless you make it nonzero. I consider it a minor issue, unless you really want the smooth movement.

If anyone manages to squash any of these, please PM me or post your fixes here if you wish to share.

i just thought of something...

you ever heard of the game TIM (the incredible machine), well you could make such a game with this too..

for the people that dont know that game, it's a building game where you can create youre own machine by dragging objects to places.

regards and thanks for this cool contribution,

Most definitely.

Yet another update.

http://www.geocities.com/hainesrs/isometric.zip - 503KB...includes all code, resources, and demo level

My theories concerning the grid snapping turned out to be fruitful, and I squashed the heck out of my problem. The only problem is is that it left me with a massive IF/ELSE monstrosity. Basically, all I added was an offset to the snap, but it has to be handled differently depending on what quadrant the 3dmouse_pos is located in.

I have no idea if it can be made more efficient by applying some fancy thinking or simplification, but I'll leave that up to someone else with more programming experience. What's there works, but it is a pain to look at. This will probably need to be converted to a CASE/SWITCH type block when that becomes available. I suppose one way to simplify it would to make sure that the level could only exist in only one quadrant. That way, you could only use the code that deals with that specific one and remove the rest. You'd have to take steps(set level bounds) to insure the player could never build outside of that section.

Anyway, I've updated the readme, and the "issues" sections in this thread. There's at least one more serious issue concerning snapping, but it only applies if you are restricting the movement of an entity to the X or Y direction. The simply way around it is simply to disable restricting. I threw that in for anyone who may need it. I most definitely would like to see it resolved, though..along with the no snapping issues I mentioned.

Model/entity management is probably going to be a huge undertaking and will make this an almost complete package. I have no idea if I'll attempt it, but if anyone gets that working, please keep us posted here. One thing to keep in mind when building for this system, you can't just place anything whereever you want. You have to keep the grid snap in mind or else you'll have areas where the entity should be able to go but can't because of a misaligned level.

Ideally, you want to have the entire play field constructed from models, but that gets into issues of collision detection, and it is a pain. It might be easier with the new collision and perhaps eve a completely different way of moving the entities. I would think you'd need to use ent_move or c_move on them so you could get some collision detection instead of the current way. Good luck.

I like this contribution. I especially like the camera, is it ok if we change it to our needs and use it or do want to leave it as is?

-Brayden Wilmoth

You're free to do anything you wish to it. This includes gutting it and using the camera/movement code for a normal game. It is essentially a Splinter Cell style cam adapted to work with this system. This means that if you press the forward key, the player will always move away from the screen. If you press left, it will always move left. It is completely independent of the camera pan and you can thank KeithB [Ambit] for it. The relevent code is in the Heromove and playerinput files, and the vars/defines used are mostly in global_defines. There may be some stragglers in playerinput.

I intentionally made it very generic so that all you had to do was change the values of the VARs to make it unique.

If you add some features or fix some of these issues, I'd love to know what you did and see the code IF you are willing to share. If not, no biggy. This goes for anyone else. The more the merrier.

this is very cool Orange Brat!

thanks a bunch

always~

Thanks Orange Brat, nice contribution. Hey Eagle, long time no see! What are you working on these days? Would love to see some of your recent projects. Glad your still around. I'm in Iraq, just kickin back and working on my new game. See ya later.. GS out.

There was some kind of bug with mouse_force in 6.22 and upgrading to 6.3 made the program go crazy. If you held down the right mouse button to rotate the view and then let up on the button, the view would continue to rotate. I fixed this, although I have no idea why it would do this given the way it was coded:

http://www.geocities.com/hainesrs/isometric.zip - 505KB...includes all code, resources, and demo level