Update Journal docs for v3.4

Sure, but that's not possible unless the repair requirements (the actual amounts, not the stupid constant 999,999 demand in the market) are actually in a journal message. And they aren't.
I was talking about:
... we're getting tired of typing updates by hand twice a day ...
You get a Docked event with "StationState": "UnderRepairs". If that is followed by a
MarketSell event you can check if the commodity is of the required type and post that to an endpoint (eg Googledoc). This no manual typing is required. It's not perfect but it's semi automatic. Maybe you can even set up an endpoint where the plugin can request station/commodity data.
 
I was talking about:

You get a Docked event with "StationState": "UnderRepairs". If that is followed by a
MarketSell event you can check if the commodity is of the required type and post that to an endpoint (eg Googledoc). This no manual typing is required. It's not perfect but it's semi automatic. Maybe you can even set up an endpoint where the plugin can request station/commodity data.
We're already working on a way to do that which works for all three platforms. I'm referring to checking how much of a given commodity is still required to complete station repairs, which we do every 12 hours and which is not programmatically possible at this time. There was also a bug that has been present since the first station attack and patched in this latest update that caused 10-25% of valid repair deliveries to not be counted towards station repairs.

We've built up a lot of automation around the repair efforts over the two years since the attacks started; happy to discuss things further if you stop by operationida.com/discord :)
 
Does anyone have a list of the "Region" to "Region_Localised" values. I know region "$Codex_RegionName_24;" is "Formorian Frontier" (because that is where I am at the moment) but getting all 41 (if I've counted right) codes would take a little more travelling that I'm comfortable with.

Many thank yous to anyone that can point me in the right direction.
 
Does anyone have a list of the "Region" to "Region_Localised" values. I know region "$Codex_RegionName_24;" is "Formorian Frontier" (because that is where I am at the moment) but getting all 41 (if I've counted right) codes would take a little more travelling that I'm comfortable with.

Many thank yous to anyone that can point me in the right direction.
There's a table on this page with them all listed:

 
There's a table on this page with them all listed:

Many thank yous Vithigar
 
Hi guys an' gals

Need a little info again. :) I'm trying to build some comparison charts of various modules. I'm hoping there is a spread-sheet (or some other e-document) that I can extract the data from rather than entering it by hand. What I'm looking for is a list of all the modules, their attributes (as given in the Journal documentation section 13.11) and their values un-engineered.

As always many thanks for any help in this.
Dobbo
 
Hi guys an' gals

Need a little info again. :) I'm trying to build some comparison charts of various modules. I'm hoping there is a spread-sheet (or some other e-document) that I can extract the data from rather than entering it by hand. What I'm looking for is a list of all the modules, their attributes (as given in the Journal documentation section 13.11) and their values un-engineered.

As always many thanks for any help in this.
Dobbo
 
Alas, the adage "be careful what you wish for" is upon me!

My SRV, with high beam on returns a Flags value of 2217263368 ... which represents bit 31 (srvHighBeam) and a whole raft of other set bits and is obviously greater than 2,147,483,647 the maximum possible 32bit signed integer.
This has caused me a bit of grief when I come to process this value within TARGET script...which is a 32bit program.

Clicker
 
Alas, the adage "be careful what you wish for" is upon me!

My SRV, with high beam on returns a Flags value of 2217263368 ... which represents bit 31 (srvHighBeam) and a whole raft of other set bits and is obviously greater than 2,147,483,647 the maximum possible 32bit signed integer.
This has caused me a bit of grief when I come to process this value within TARGET script...which is a 32bit program.

Clicker
A program being 32-bit has little or nothing to do with the maximum values available for the variables it uses. Can you just declare a long or uint instead of an int?
 
Hi @Vithigar ,

I'm not super conversant in C or C++ which TARGET Script is (loosely) based on...but I'll give that a try.

What I'm currently doing is opening the status.json file, scanning for "Flags:", then reading in the key value as a string.
TARGET has a built in function called 'ieval(alias s){}' which converts text and returns its integer equivalent.
When I get home tonight, I'll see if TARGET allows/recognises 'long', or 'uint'.

In the meantime, when the SRV has High Beam on, the Flags key value returned is a negative integer.
My work around assumes this is a wrap-around, so I set my internal "srvHiBeam" flag, then carry on processing the remainder, thus setting any other flags I'm tracking.

Clicker
 
What I'm currently doing is opening the status.json file, scanning for "Flags:", then reading in the key value as a string.
TARGET has a built in function called 'ieval(alias s){}' which converts text and returns its integer equivalent.
When I get home tonight, I'll see if TARGET allows/recognises 'long', or 'uint'.
If it doesn't work you could workaround it by (pseudo code):
Code:
if value < 0:
  highbeam = True
  value = value + 2147483647
  value = value + 1
I use two additions because if the language doesn't support unsigned integers 2147483648 will be too large to add in one go.

edit: Or, if it does support bitwise and operation:
Code:
if value < 0:
  highbeam = True
  value = value & 2147483647
 
Last edited:
Hi @Vithigar ,

I'm not super conversant in C or C++ which TARGET Script is (loosely) based on...but I'll give that a try.

What I'm currently doing is opening the status.json file, scanning for "Flags:", then reading in the key value as a string.
TARGET has a built in function called 'ieval(alias s){}' which converts text and returns its integer equivalent.
When I get home tonight, I'll see if TARGET allows/recognises 'long', or 'uint'.

In the meantime, when the SRV has High Beam on, the Flags key value returned is a negative integer.
My work around assumes this is a wrap-around, so I set my internal "srvHiBeam" flag, then carry on processing the remainder, thus setting any other flags I'm tracking.

Clicker
Well, I just read the TARGET script manual and downloaded and looked at the software. Yeah, there's no long or uint data type. The language is pretty crippled.

That said, getting the negative value can still let you grab the flags you need. I'm not sure how you're "unwrapping" the overflowed value, but if you see a negative you know the srv high beams flag is set and can do a bitwise AND against 2147483647 (this unsets the highest bit in a signed 32-bit int but leaves the rest alone) to read the remainder of the flags (remainingFlags = allFlags & 2147483647).
 
Thanks @gazelle & @Vithigar ,that’s what I’m doing, pretty much.

if(Flags<0) srvHiBeam=1 else srvHiBeam=0;
After that,my bitwise and (&) test against the rest of the bits works fine.

If they add any more bits to Flags, I’ll need to workout another way to process.

Cheers
 
hi all... I have been looking at the RedeemVoucher event. it looks like when you use a Legal Contract to had in your bounties, the faction name is left blank within the factions array

Handed in at station with faction.
{ "timestamp":"2020-02-17T12:03:11Z", "event":"RedeemVoucher","Type":"bounty","Amount":304957, "Factions":[ {"Faction":"HIP 59419 Services","Amount":304957 } ] }

handed in at remote station to faction using legal contact
{ "timestamp":"2020-02-17T12:03:59Z", "event":"RedeemVoucher","Type":"bounty","Amount":333543,"Factions":[ {"Faction":"","Amount":333543 } ],"BrokerPercentage":25.000000}

whats the best way to get this fixed, do we add this to the issue tracker?
 
Last edited:
Top Bottom