Vega Strike Forums

Ok, I've updated my editor.

Added the prebuilt bars: you can choose from mining, ice, industrial, agricultural, and ocean.

Added fixers. Not much control over what kind, but you can drop them in place.


Current status:
Rooms: Working
Backgrounds: Bases not reading jpgs
Naming rooms: Working
Room Links: Working, but misplaced
Computers: Working, but misplaced
Place Ship: Unsure of vector info
Place Launch: Working, but misplaced
Place Fixer: Working, but misplaced
Load Music: Included, but Untested
Import Base: Major experimentation to load existing bases
Compile to Base: Working
Place pre-built bars: Working, but misplaced
Place guilds: Pending

Here is the repo again
https://ppueditor.svn.sourceforge.net/s ... asecrafter


I never took calculus, but my math comprehension is good. (My computation, not so much.) I'm not finding much on turning x,y,z rotations into the vectors needed for VS, If I can get that working I might be willing to call it beta, or at least solidly in the alpha stage.


Pheonixstorm, I think I found your problem with it, and tried to set up an error catcher. Point the bases folder under your data folder, and the data folder into an install of VS (the data folder).

travists - from my very limited experience with maths etc...

After reading through this thread entirely, I get the impression that what you need to understand is regarding converting the pixel positions to vectors.

If the vectors are ranged 0 to 1 and 0,0 being the upper left (for example) and 1,1 being the lower right (again for example) then I would imagine the math would be something like this...


Assume a screen size of 1024 x 768 for this exercise

0,0 is top left pixel and 1023, 767 is bottom right pixel.

A vector position of 0.5, 0.5 should be the centre of the screen which would translate to a pixel position of 511, 383.

I think what you need to do to get the vector number would be as follows...

Vector x = ((1 / (screen width / pixel position x))
Vector y = ((1 / (screen height / pixel position y)

to clarify the formula

Firstly you divide the screen width assume it as the (x Axis) by the pixel position. this will give a number eg if it is in the centre that number will be 2, if it is to the right of the screen it will be closer to 1 and if it is near the left of the screen it will be higher than 2 (as high as 1023 if it is on the very left edge of the screen)

You then divide 1 by this number.

If the pixel is on the far right and so the number will be 1 then the math will be 1/1 which = 1 so that fits inside the vectors max range.

anything less than the far right and still to the right of the middle will return a number between 0.51 and 0.99 approximately

if the pixel is against the far left then the math will be 1/1024 which = 0.0009765625 or really close enough to zero

the reason for the way I have braced the formula is to force the order of which part of the equation is calculated first.

By chance if this is wrong and someone else can see an error in this proposition for converting from pixel position to vector please educate me and explain how its done

also note that this is just for converting from screen pixel locations to vectors for the room links, computer locations etc not for the ship placement and orientation...

I am currently trying to understand how that works reading up on matrix's etc

Thanks, scallipus.

I'll give that a shot, though it is quite similar to my present method: see if that aligns them better, though without it loading the background pictures in correctly, it's hard to tell.

The vectors I really have trouble with is the rotational ones for placing the ship. I'll look in more detail at your post see what nuggets of joy I can parse out.

Orthonormal basis are usually specified in triplets: P, Q, R.

If the above is true for vegastrike (P, Q, R) are the columns of the rotation matrix.



http://en.wikipedia.org/wiki/Rotation_r ... ematics%29

Right click and 'view image'. It's black text.

travists

i did notice an error on my formula sorry

where it reads ((1 / (screen width / pixel position x))
it should have read (1/(screen width / pixel position x))

I was pretty tired last night sorry for that.

Also after doing some playing around this morning... the forumla could simply be changed to
vectorX = (pixel position X / screen width) which returns the same values as the above with just a little less precision - we are not talking about any major precision losses tho.
to make it in the negative range you would have vectorX = ((pixel position X / screen width) -1)

what is the problem you are having with loading the jpeg image?

scallipus wrote: what is the problem you are having with loading the jpeg image?

Seems to be more of an engine issue, I can load jpegs into my program without problem. I can save the path into the script. It seems that the game isn't loading unencoded jpgs. I've been playing with the rest of it to get the various tools working, just assuming that that was the problem. Of course the best way to remember how to spell "assume" is by what it can do. (Don't know? Break it down into it's syllables! )

If I’m wrong, or there is something to add into the script to fix this let me know please!

FYI, I've been teaching myself programming since QBasic. Even had some classes in programming in college. It's not the coding that is the hang-up, it's the code. Then again, as I am largely self-taught, I have some bad habits and sloppy coding.

At such time as the backgrounds are working I can try both conversion techniques, and see if one is better than the other. Thanks for you willingness to lend a hand too!

Just did some quick testing before calling it a night. a .jpg extention does not load, nor does running it through nvcompress to get a .dds, how do I get a .spr?

the spr is nothing more than a simple text file that points to all the other needed files or other information required by that particular unit/base whatever. Do a search in data for spr and you will find a lot of examples.

Great... another layer of scripting to figure out


OK,
Line 1: the image path (what the heck is a .image file?)
Line 2: size?
Line 3: origin?


I'll see if it likes jpgs in there, if not I'll still need to figure out how to do a convertion.
I'm closer, yeah!!!

An 800 x 600 jpg works, but is very slow. I should have more data on how out of place the hotspost are soon.


***Edit: They wern't as far off as I thought. Some quick tweaks and the hotspots are very close to where you put them. Let me know how to encode the jpgs to image, or if that would even be the problem, and I can change the background status Thanks all!

the .image and .texture files are nothing more than renamed dds files. dds is a compressed image format used by most games to make the texture sizes much smaller so more can be loaded into memory. So, if you want to load the bases graphics directly (if they are .image or .texure) you will need to have some way of reading a dds file in your program. Being windows based you can probablly use some directx call for it or should find some library for reading dds files online somewhere.

I'll look for that. Would it be too much to ask that the user download nvcompress? Run that utility as an external, then rename the file? Everything is working great for a 800x600 jpg, I would like to have more flexibility though. As I indicated a post or two back, it looks to me like the second line in the .spr file is a size possibly percentage? If that is the case I can automaticly generate the info, but don't know the ratio it uses. Looks like everything is comming together! Then comes the switch to walkable bases and it won't get used But, as a modding tool for other projects using the engine it may be handy.

OW! My brain hurts! I can't find a plug-in, but I was able to get nvcompress to launch from within my base maker. Had to have the program write a batch file, then run that. Now I'll need to have it make a .spr file Time to give it a rest I think! Not ready to post an update, but here is a progress report

Current status:
Rooms: Working
Backgrounds: Problem found, solution pending
Naming rooms: Working
Room Links: Working, posistion acceptable
Computers: Working, posistion acceptable
Place Ship: Unsure of vector info
Place Launch: Working, posistion acceptable
Place Fixer: Working, posistion acceptable; sizing ???
Load Music: Included, but Untested
Import Base: Major experimentation to load existing bases
Compile to Base: Working
Place pre-built bars: Working, posistion acceptable
Place guilds: Pending

travists - re the DDS images

http://www.modwiki.net/wiki/DDS_%28file_format%29

There is some handy information along with links to some tools for creating the DDS files.

also this might be handy reading as you are writing in VB yes?

http://directx4vb.vbgamer.com/DirectX4V ... 9Start.asp

and yes I do know what to 'assume' breaks down to

Took a look at those, looks to be handy, just not here. Can we dig up someone that worked on the original engine (not literaly I hope), that might know how to do the convertion from pqr to xyz? Most everything else is comming along, just have to brace myself for another go at it.

Right hand rule may give a little insight.

I've been struggling with pqr myself though, complicated stuff to do by heart.

p = vector pointing in world coordinates where local x should go

q = vector pointing in world coordinates where local y should go

r = vector pointing in world coordinates where local z should go

Now... there is a slight chance that p isn't what I said above, but instead the center of coordinates. I'd have to inspect the code.

I'll get back to you with the answer shortly.

EDIT: Effectively, P = position (local center of the ship), Q = "up" or "+y" vector, R = "front" or "+z" vector.

Thanks, now that I have some basis to go on, I guess it's "guess and check". Getting closer.

I've found it!!!

http://vegastrike.sourceforge.net/wiki/ ... ackgrounds

Ship placement

Base.Ship (room1, 'ship', (-0.3, -0.3, 6), (0, 0.93, -0.34), (-1, 0, 0))The above code defines the placement for the ship in room1, assuming room1 is the landing pad room or the repairs and upgrades room, where the player's ship should show. It has the form: Base.Ship (roomvariable, linkname, vectorP, vectorR, vectorQ)

where:

roomvariable - the room in which you place the button
linkname - arbitrary name to make your code readable
vectorP - position of the ship with (centerx, centery, scale) -- Note that scale is a Z coordinate in perspective, so you must adjust your X and Y accordingly as it gets farther away.
vectorR - ship up orientation with up-vector coordinates (x, y, z)
vectorQ - ship nose orientation with forward-vector coordinates (x, y, z)
Testimonial by chuck_starchaser

Adjusting these vectors (particularly the up and forward) manually, by trial and error, can be very time consuming and tedious. The sum of the squares of the x, y and z values in the up and forward vectors must add to one. In other words, the vectors should be "normalized", or of "unit-length". Also, the up and forward vectors should be normal (perpendicular) to one another. In arithmetic terms, their dot product should be zero. And what's the dot-product? The result of multiplying up.x times forward.x, adding to that the product of up.y times forward.y, and adding to that the product of up.z times forward.z. That should be zero if the two vectors are perpendicular. Yes; it's Hell; been there and survived.

Anyone a better head at math than me? I'll look at the wikipedia info again, later, to see if it works now.

The up and forward vector define the orientation - up should point the direction in "screen" coordinates the ship's top should face, and forward is the direction (in screen coordinates) the nose should face.

Now, both up and forward vectors must be what it's called an "orthonormal" basis, which means that they must be vectors of length 1, and they should lay at 90 degrees from each other. Mathematically, you check that by computing its norm ( sqrt(x² + y² + z²) = 1 ) and their dot product, which is equals to the cosine of the angle formed by the two vectors ( dot(a,b) = a.x*b.x + a.y*b.y + a.z*b.z = cos(angle) and if angle = 90 deg -> cos(angle) = 0 ).

The two constraints on up and forward are rather intuitive (forward and up should always form a 90 degree angle, if they are indeed up and forward directions). If you have non-normal vectors (ie, their length isn't 1), you can normalize them very easily: normalized(x,y,z) = (x/length, y/length, z/length).

Did you get anywhere with this? The thread kinda stops here - How viable is it as a base editor? or the DB editor? What of the mission editor/wizard?