SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

Status
Not open for further replies.
I have reconfigured. One more time?

It's moving forward as I now got a dialog asking for the login, but then it gives a Can't open file '/svn/shuttleultra/db/txn-current-lock': Permission denied message.
 
It's moving forward as I now got a dialog asking for the login, but then it gives a Can't open file '/svn/shuttleultra/db/txn-current-lock': Permission denied message.

I hope this is not due to me cloning it with git currently (to test for history differences).
 
I hope this is not due to me cloning it with git currently (to test for history differences).

IMO, if there is a problem, it should actually be the other way around. Could me committing something mess up your test?
 
IMO, if there is a problem, it should actually be the other way around. Could me committing something mess up your test?

It would just show a difference in commits, but should not show a difference in common commits. Cloning has gone through already, so if my concurrent read-action had an influence on your write-action, it should be gone now.
 
It would just show a difference in commits, but should not show a difference in common commits. Cloning has gone through already, so if my concurrent read-action had an influence on your write-action, it should be gone now.

As expected, it wasn't that.
 
It's moving forward as I now got a dialog asking for the login, but then it gives a Can't open file '/svn/shuttleultra/db/txn-current-lock': Permission denied message.

No, that'll be a permissions issue on the repository files within the container itself. I've reset them to the same user as is running the SVNServe daemon, please try again.
 
No, that'll be a permissions issue on the repository files within the container itself. I've reset them to the same user as is running the SVNServe daemon, please try again.

Still showing the same error. :(
 
Another permissions change, how's that?
 
Another permissions change, how's that?

Different error:
Code:
Commit failed (details follow):
Can't move '/svn/shuttleultra/db/txn-protorevs/2817-269.rev' to
 '/svn/shuttleultra/db/revs/2/2818': Permission denied
 
This is very frustrating and confusing, but I've made another change that might help. It's a bit trial and error, sorry about this.
 
This is very frustrating and confusing, but I've made another change that might help. It's a bit trial and error, sorry about this.

It worked!!!!!!!!!!!!! :woohoo::woohoo:
Thank you so much!!! :cheers:
:hailprobe:
 
It worked!!!!!!!!!!!!! :woohoo::woohoo:
Thank you so much!!! :cheers:
:hailprobe:
Yep, everything seems to be A-OK, including project monitoring through TortoiseSVN Project Monitor.
 
The merge from hell is done!
finally-its-done.jpg


Absolutely 0 (zero) problems, smooth as glass, both in a test merge and the real thing. If there was any doubt the issue was in SFs side, there is none now.

---------- Post added at 07:11 PM ---------- Previous post was at 07:07 PM ----------

I now have to install Orbiter in the checkout folder and setup things... probably it will take the rest of the day. Tomorrow I should arrive at the point I was exactly one month ago.
 
When should the password be necessary? :hmm: Sorry for the longer delay there, had been in a different universe for some days.
 
When should the password be necessary? :hmm: Sorry for the longer delay there, had been in a different universe for some days.

When you do a write operation in the server? :shrug:
 
Ok, so there are some ancient branches that could be deleted as they are not, and IMO, will not be used:
OI-1 (1 change, last used July 2011)
SSUToolbox (8 changes, last used March 2014) (I think this was replaced by SSUW)
3.0-release (0 changes)

If there are no objections, I'll send them on their merry way.
 
I've moved the HUD logic to a subsystem (one instance only, at least for now), instead of that being done by the AerojetDAP, but I'm having difficulties in getting data from the GPC to there. So I'm thinking about adding some sort of "bus system" and "common memory" so things can move forward (at least for a while).

So, one class running before our "GPC sw user" classes, and according to MM requests data from the appropriate subsystems, and then another class running at the end that commands things.
Inside the GPC, these classes read and write to a big array that is accessible by all SimpleGPCSoftware classes, and can also be used for them to talk to each other.

We would have a single bus (we only have 1 GPC :shrug:) controlled by a bus manager that gets calls to send command and data words and broadcasts them to everyone in the bus, who then checks if the message ID matches its own ID, and if so does "things" and if needed responds with another message(s) to the bus manager.

For the user this would not really change things, as there isn't any reconfiguration possible, but behind the curtains it should ease data flow.

My only concerns ATM are:
1) about handling different data types in the "poor man's COMPOOL" and also in the bus data words. memcpy-ing a float into 2 shorts, and send 2 data words per float? :shrug:
2) scenarios need to save the shared data
 
Need the definition of the original data transmitted between HUD/flight instruments and GPC? Its a simple single struct.

Yes, a 32 bit floating point number would be transmitted as 2 words. But the HUD used fixed point numbers anyway.
 
Need the definition of the original data transmitted between HUD/flight instruments and GPC? Its a simple single struct.

Yes, a 32 bit floating point number would be transmitted as 2 words. But the HUD used fixed point numbers anyway.

Yes that would help.
ATM, the HUD needs roll, pitch, TAEM and AL phase IDs, altitude, velocity (KEAS and KGS?), OGS angle and aimpoint, SB command and position. Still have to figure out the runway position and guidance diamond parts... :facepalm:

---------- Post added at 03:58 PM ---------- Previous post was at 01:48 PM ----------

I've created a branch for this work... feel free to use your new password. :P
I think we could start with getting the EIUs using the new system, as it has a lot of back-and-forth, and if it does the job there it should work for the rest.
 
Status
Not open for further replies.
Back
Top