SSU Development Thread (2.0 to 3.0)

[GLS]

About the new talkbacks, can we edit the groups directly with this?

	/**
	* \brief Returns a pointer to the group specification of a mesh group.
	* \param hMesh mesh handle
	* \param idx group index (>=0)
	* \return pointer to mesh group specification (or NULL if idx out of range)
	* \note \b MESHGROUP is a structure that contains the components of the
	*   group, including vertex list, index list, texture and material index.
	* \note This method can be used to edit the a mesh group directly (for geometry
	*  animation, texture animation, etc.)
	* \note This function should only be applied to device-independent meshes,
	*   such as mesh templates.
	* \note For device-dependent mesh instances (such as returned by
	*   \ref VESSEL::GetDevMesh) use \ref oapiEditMeshGroup instead.
	* \sa oapiEditMeshGroup
	*/
OAPIFUNC MESHGROUP *oapiMeshGroup (MESHHANDLE hMesh, DWORD idx);
OAPIFUNC MESHGROUP *oapiMeshGroup (DEVMESHHANDLE hMesh, DWORD idx);

Or for us this just to get the data for a group?

Never mind that.
So I managed to come up with something that works.... sometimes. I think the "core" is good, but there's some issues to work out: doesn't work in D3D9, it updates after the first frame (instead of before) and it's still missing the "reset" part for when the visuals are re-created during the simulation. Other than that it does what it was expected. I've redone the talkback.dds texture to have bigger talkback "labels", and I'm using panel R13L for testing as it already has all the talkback groups in the correct place and they use the talkback.dds texture, so I just had to tweak the UVs of those groups in the mesh to lineup correctly.

---------- Post added at 03:13 PM ---------- Previous post was at 03:07 AM ----------

Talkback status report: fixed 2 of the 3 problems above, but it still doesn't work in D3D9. The problem seems to be the call to oapiMeshGroupEx (to get the current UVs), as it returns trash in D3D9 but works as expected in MOGE. If I use oapiMeshGroup it goes BUM in both clients.

 

[DaveS]

Never mind that.
So I managed to come up with something that works.... sometimes. I think the "core" is good, but there's some issues to work out: doesn't work in D3D9, it updates after the first frame (instead of before) and it's still missing the "reset" part for when the visuals are re-created during the simulation. Other than that it does what it was expected. I've redone the talkback.dds texture to have bigger talkback "labels", and I'm using panel R13L for testing as it already has all the talkback groups in the correct place and they use the talkback.dds texture, so I just had to tweak the UVs of those groups in the mesh to lineup correctly.

---------- Post added at 03:13 PM ---------- Previous post was at 03:07 AM ----------

Talkback status report: fixed 2 of the 3 problems above, but it still doesn't work in D3D9. The problem seems to be the call to oapiMeshGroupEx (to get the current UVs), as it returns trash in D3D9 but works as expected in MOGE. If I use oapiMeshGroup it goes BUM in both clients.

Maybe you should post about oapiMeshGroupEx's behavior in the D3D9Client thread? If it indeed is not working D3D9Client but the inline client maybe it is a D3D9Client bug that needs attention?

 

[Urwumpe]

Everything that is DEVMESHHANDLE based should work on a graphics client.

 

[GLS]

This is the code:

		if (STS()->hDevVCMesh == 0) return;
		MESHGROUPEX* mg = oapiMeshGroupEx( STS()->hDevVCMesh, grpIndex );

		for (unsigned short i = 0; i < mg->nVtx; i++)
		{
			mg->Vtx[i].tu += (TALKBACK_U_OFFSET[tkbk_next_state] - TALKBACK_U_OFFSET[tkbk_state]);
			mg->Vtx[i].tv += (TALKBACK_V_OFFSET[tkbk_next_state] - TALKBACK_V_OFFSET[tkbk_state]);
		}
		tkbk_state = tkbk_next_state;

		GROUPEDITSPEC grpSpec;
		grpSpec.flags = GRPEDIT_VTXTEX;
		grpSpec.Vtx = mg->Vtx;
		grpSpec.nVtx = mg->nVtx;
		grpSpec.vIdx = NULL;
		oapiEditMeshGroup( STS()->hDevVCMesh, grpIndex, &grpSpec );
		STS()->MeshModified( STS()->hDevVCMesh, grpIndex, 0 );

After the call in the 2º line is made, accessing mg does BUM. And yes. it's using DEVMESHHANDLE.

 

[jarmonik]

I'll take a look and let's see what I can find. I'll report back.
Edit: What's a MOGE ?

 

[GLS]

I'll take a look and let's see what I can find. I'll report back.
Edit: What's a MOGE ?

Martin's Own Graphics Client :rofl:
Anyway, with some help, this seems to be working now. Instead of giving the DEVMESHHANDLE to oapiMeshGroupEx, I now give the GetMeshTemplate handle. This way, D3D9 works as expected, except now the log file has several lines "EVENT_VESSEL_MODMESHGROUP Not Implemented".:shrug:

 

[jarmonik]

First of all: MeshModified() and oapiMeshGroupEx() do not use DEVMESHHANDLE. So, Try passing a template mesh handle to oapiMeshGroupEx().

Also it looks like MeshModified() message isn't handled in the client yet due to lack of implementation details. oapiEditMeshGroup() does sent all necessary update calls to a client, so MeshModified() should not be needed. I am assuming that MeshModified() is intended to be used if there is a change in a template mesh.

---------- Post added at 18:50 ---------- Previous post was at 18:48 ----------

Martin's Own Graphics Client :rofl:
Anyway, with some help, this seems to be working now. Instead of giving the DEVMESHHANDLE to oapiMeshGroupEx, I now give the GetMeshTemplate handle. This way, D3D9 works as expected, except now the log file has several lines "EVENT_VESSEL_MODMESHGROUP Not Implemented".:shrug:

Does it work if you remove MeshModified() call ?

 

[GLS]

First of all: MeshModified() and oapiMeshGroupEx() do not use DEVMESHHANDLE. So, Try passing a template mesh handle to oapiMeshGroupEx().

Also it looks like MeshModified() message isn't handled in the client yet due to lack of implementation details. oapiEditMeshGroup() does sent all necessary update calls to a client, so MeshModified() should not be needed. I am assuming that MeshModified() is intended to be used if there is a change in a template mesh.

Does it work if you remove MeshModified() call ?

If I use the template mesh on all 3 calls it seems to stay unchanged (but doesn't crash. Removing the MeshModified call at the end doesn't change anything and it still remains unchanged. Using the DEVMESHHANDLE in oapiEditMeshGroup works (even without MeshModified). Without MeshModified the lines "EVENT_VESSEL_MODMESHGROUP Not Implemented" don't show up.

---------- Post added at 05:08 PM ---------- Previous post was at 05:01 PM ----------

Went back to MOGE and it now messes things up :facepalm:.

---------- Post added at 05:17 PM ---------- Previous post was at 05:08 PM ----------

So, copied the vertex array instead of using it directly, and it now seems to work on both D3D9 (without the line in the log) and MOGE!
Here's how it stands ATM:

		if (STS()->hDevVCMesh == 0) return;
		MESHHANDLE VCMeshTemplate = STS()->GetMeshTemplate( STS()->mesh_vc );
		MESHGROUPEX* mg = oapiMeshGroupEx( VCMeshTemplate, grpIndex );

		NTVERTEX* Vtx = new NTVERTEX[mg->nVtx];
		for (unsigned short i = 0; i < mg->nVtx; i++)
		{
			Vtx[i].tu = mg->Vtx[i].tu + (TALKBACK_U_OFFSET[tkbk_next_state]);
			Vtx[i].tv = mg->Vtx[i].tv + (TALKBACK_V_OFFSET[tkbk_next_state]);
		}
		tkbk_state = tkbk_next_state;

		GROUPEDITSPEC grpSpec;
		grpSpec.flags = GRPEDIT_VTXTEX;
		grpSpec.Vtx = Vtx;
		grpSpec.nVtx = mg->nVtx;
		grpSpec.vIdx = NULL;
		oapiEditMeshGroup( STS()->hDevVCMesh, grpIndex, &grpSpec );

		delete[] Vtx;

I'll keep on testing all the situations that come to mind.
Thanks to everybody involved!

---------- Post added at 11:48 PM ---------- Previous post was at 05:17 PM ----------

SVN is up!!!!
The code page is now loading and I also just did a "Show log" from tortoise and it worked well. Looks like no data was lost as the last revision shown is the correct one. Still no official "confirmation" in their blog or twitter that the system is up. Let's now wait to see if things don't go bad, and say, tomorrow morning we resume commits.

 

[DaveS]

SVN update: Seems like things are returning to normal. The 503 message is gone and it is fully possible to browse the repositories. And it is responding to TortoiseSVN commands as well. I would wait another 24 hours for things to stabilize before we start checking things in. There's no official update available from Sourceforge yet.

 

[GLS]

It's official now: SourceForge Subversion (SVN) service online

SourceForge-hosted Allura-backed Subversion (SVN) repositories have been restored to service as of 7/25. In addition to other checks, a representative sample of data has been tested using ‘svnadmin verify’ and a functional test performed (commit and/or checkout via http, ro svn, rw svn+ssh, etc.).

 

[DaveS]

Can someone verify that we lost a revision (2159)? The latest that's in the repository is revision 2158.

 

[GLS]

Can someone verify that we lost a revision (2159)? The latest that's in the repository is revision 2158.

You might be right. Upon futher checks I do have at least 2 files from r2159 dated from 16/07/15 04:36:59AM. That was almost certainly a commit made by me. I'll digg a bit more to see if I can find what I changed.

 

[GLS]

So, managed to find the files changed in r2159 (list in the attached image).
I'll have to do a "manual" comparison of these files against what they were in r2158 to extract the differences, separate those changes from the ones I've made since then, re-apply and re-commit them.
I'll wait until the morning to start the process. Who knows, maybe the lost revision will show up, and even if it doesn't, I won't be as tired as I am now.

 

[Urwumpe]

So, copied the vertex array instead of using it directly, and it now seems to work on both D3D9 (without the line in the log) and MOGE!

Remember to also subtract the coordinates of the old state from the texture coordinates so you are not shifting the texture with every update.

EDIT... since new and malloc() are pretty slow, would it be possible to use a static vertex buffer in the DLL or must we create a new array of vertex coordinates in every modification?

I am sure I managed to do this differently in a test.

 

[GLS]

So.... I don't have good news. The 8 files changed in (the now lost) r2159, I tried to get them back in r2158, using "revert", "update" and "update to revision", but I always get the error "no such revision 2159".:facepalm:
So it looks like I'm "locked out" at the moment. I (and probably everybody in r2159) will have to create a new repository folder... unless, we could fool the system by creating a "fake" r2159 with some meaningless change (or probably better: the files from 2159), thus "unlocking" this error. But this needs to be done by someone (with commit access) in r2158 (or less). You can check if you fulfill this "requirement" by going to "\trunk\Orbitersdk\Space Shuttle Ultra\vc" and in the properties for PanelO6.cpp, check the revision number in the tortoise tab.

Remember to also subtract the coordinates of the old state from the texture coordinates so you are not shifting the texture with every update.

EDIT... since new and malloc() are pretty slow, would it be possible to use a static vertex buffer in the DLL or must we create a new array of vertex coordinates in every modification?

I am sure I managed to do this differently in a test.

This will have to wait as right now I'm trying to get SVN sorted out. Don't worry I'll get back to it ASAP.

 

[DaveS]

So.... I don't have good news. The 8 files changed in (the now lost) r2159, I tried to get them back in r2158, using "revert", "update" and "update to revision", but I always get the error "no such revision 2159".:facepalm:
So it looks like I'm "locked out" at the moment. I (and probably everybody in r2159) will have to create a new repository folder... unless, we could fool the system by creating a "fake" r2159 with some meaningless change (or probably better: the files from 2159), thus "unlocking" this error. But this needs to be done by someone (with commit access) in r2158 (or less). You can check if you fulfill this "requirement" by going to "\trunk\Orbitersdk\Space Shuttle Ultra\vc" and in the properties for PanelO6.cpp, check the revision number in the tortoise tab.



This will have to wait as right now I'm trying to get SVN sorted out. Don't worry I'll get back to it ASAP.

I fixed this by checking a LC39 change I did yesterday (RSS rotation time and offset). So this is no longer an issue. Revision 2159 now exists again.

---------- Post added at 01:24 PM ---------- Previous post was at 01:15 PM ----------

Only thing is that the revision description on the web site is that of the former 2159 which was this:

>> in SPEC 50, added flashing attribute to orbiter symbol and Nz value when it exceeds limits
>> corrected a switch animation and changed the GPC Mode switches to the correct lockable levers on panel O6
>> added ADI switches to panel A6U

And it was by gls_ssu 2015-07-16

 

[GLS]

I fixed this by checking a LC39 change I did yesterday (RSS rotation time and offset). So this is no longer an issue. Revision 2159 now exists again.

---------- Post added at 01:24 PM ---------- Previous post was at 01:15 PM ----------

Only thing is that the revision description on the web site is that of the former 2159 which was this:



And it was by gls_ssu 2015-07-16

But my changes from the old 2159 aren't in the system. You probably should have commited those changes... but now doesn't matter. The website now has both descriptions, but in separate areas.
Please hold on further commits to see if I can add the changes from the old r2159.

 

[DaveS]

But my changes from the old 2159 aren't in the system. You probably should have commited those changes... but now doesn't matter. The website now has both descriptions, but in separate areas.
Please hold on further commits to see if I can add the changes from the old r2159.

I think we all should be added as project admins so that any one of us can effect project changes in cases like this when the others are not available.

---------- Post added at 02:14 PM ---------- Previous post was at 01:56 PM ----------

Could you post the the changed lines from the old 2159? Maybe they're still there and it's just that the top level got borked?

 

[GLS]

I think we all should be added as project admins so that any one of us can effect project changes in cases like this when the others are not available.

---------- Post added at 02:14 PM ---------- Previous post was at 01:56 PM ----------

Could you post the the changed lines from the old 2159? Maybe they're still there and it's just that the top level got borked?

The changes made in the old r2159 are not in the server, but they are on my "r2159 version". I can't change those files, as the checksum is now different... :facepalm:
I think I'm going to have to delete the SVN folder and start the whole repository again here, and then go back to my backup and manually copy my changes, both the old r2159 as well as from the last week. :compbash:

 

[DaveS]

The changes made in the old r2159 are not in the server, but they are on my "r2159 version". I can't change those files, as the checksum is now different... :facepalm:
I think I'm going to have to delete the SVN folder and start the whole repository again here, and then go back to my backup and manually copy my changes, both the old r2159 as well as from the last week. :compbash:

Yeah that looks like the way to go unfortunately.