SSU Development Thread (2.0 to 3.0)

[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.

 

[GLS]

Yeah that looks like the way to go unfortunately.

Just started to download everything again...
Please hold on commits, so I can get the stuff from the lost r2159 out of the way first, and then we can move on to other stuff.

---------- Post added at 06:55 PM ---------- Previous post was at 02:03 PM ----------

So, after hours downloading, I finally have the whole thing! Just give me a few more minutes to setup everything (orbiter/orbitersound/d3d9), run a couple of tests to make sure all is well and then I'll commit the lost r2159 changes.

 

[DaveS]

Just started to download everything again...
Please hold on commits, so I can get the stuff from the lost r2159 out of the way first, and then we can move on to other stuff.

---------- Post added at 06:55 PM ---------- Previous post was at 02:03 PM ----------

So, after hours downloading, I finally have the whole thing! Just give me a few more minutes to setup everything (orbiter/orbitersound/d3d9), run a couple of tests to make sure all is well and then I'll commit the lost r2159 changes.

Yeah, I think the biggest thing in the repository is the orbiter texture source file (Orbiter_blank.psd, 56 758 kB). And with the really slow connection speed that Sourceforge provides, checking out/in that file takes a long time. I'm think it should be removed to speed up the entire process.

 

[Urwumpe]

Yeah, I think the biggest thing in the repository is the orbiter texture source file (Orbiter_blank.psd, 56 758 kB). And with the really slow connection speed that Sourceforge provides, checking out/in that file takes a long time. I'm think it should be removed to speed up the entire process.

I don't think it should be removed, since it is an important source file for SSU and we usually only need to check it out once.

But a faster VCS would be nice to have now.

 

[DaveS]

I don't think it should be removed, since it is an important source file for SSU and we usually only need to check it out once.

But a faster VCS would be nice to have now.

Yes, I have wished for that for a long time. Best transfer speed I have seen is about 8 kB/s. But usually it's about half that, 4 kB/s.

 

[GLS]

Yeah, I think the biggest thing in the repository is the orbiter texture source file (Orbiter_blank.psd, 56 758 kB). And with the really slow connection speed that Sourceforge provides, checking out/in that file takes a long time. I'm think it should be removed to speed up the entire process.

That is a big file, but it's not that. The download speed is quite low, and it's not limited on my end (not that it's super fast). It has always been painfull to download the whole thing, regardless of the connection, computer, place, etc.
So, I've done all the testing and it seems to be ok. I'll now commit the lost changes so then you can check if things are well in your end.

 

[Urwumpe]

Yes, I have wished for that for a long time. Best transfer speed I have seen is about 8 kB/s. But usually it's about half that, 4 kB/s.

The main problem with the transfer speed is the communication overhead, large files actually arrive pretty well on my end. But yes, its slow, texture and mesh updates usually take a while to update.