32bit vs 64 bit

[linuxgurugamer]

I've had a report from a user that one of my mods (EEX) doesn't work under 32 bit, but it does under 64 bit.  Has anyone else run into this?

If so, is there something I can to for 32 bit?

[Warezcrawler]

Just tested it on 32bit... And yes something is wrong.... Things like offsetlimit does not function as on 64bit, i.e. not at all in 32bit.

I've notice that we are building plugins against dll's in either x64 or x32 directories, so I'm guessing you are utilizing some methods that are different between the two build...

I can say that EEX does work for me in x64. While it's annoying that it might not function in x32, maybe a disclaimer on the plugin is the way to go. One could ask the question of why use x32 now that we have access to x64 build?

Sorry that I could not be more helpfull. Maybe some else have a better response for you.

[NathanKell]

@linuxgurugamer this feels like about the third time I have told you this. I am telling you this one more time. Please listen this time. Do not use the names of private fields when reflecting. They are not reliable. You can use the order in which they appear, or anything else that strikes your fancy, but do not use their names.

Ok?

[linuxgurugamer]

4 minutes ago, NathanKell said:

@linuxgurugamer this feels like about the third time I have told you this. I am telling you this one more time. Please listen this time. Do not use the names of private fields when reflecting. They are not reliable. You can use the order in which they appear, or anything else that strikes your fancy, but do not use their names.

Ok?

I know, yes, you've told me, and I need some time to redo it.  The original author used obfuscated field names, which didn't translate well to 1.1.  I don't yet know enough c# to yet do the replacement with what you describe.  This is why I asked tat they be made available via the EditorLogic.fetch.

So, can you point me to a method by which I can determine the order of the fields?

Thanks

[NathanKell]

@linuxgurugamer Ah, ok. Apologies for coming down like a ton of bricks then. :]

The order will be the same in 32bit and 64bit, so you can dump the order from 64bit and use that.

[linuxgurugamer]

4 minutes ago, NathanKell said:

@linuxgurugamer Ah, ok. Apologies for coming down like a ton of bricks then. :]

The order will be the same in 32bit and 64bit, so you can dump the order from 64bit and use that.

Apology accepted.  :-)

So, the order, is that just the position from the beginning?   Can you point me to an example somewhere?

I won't be online for a day or so, will check when I get back

[NathanKell]

@linuxgurugamer The order you get when you iterate over the fields in the type.

[linuxgurugamer]

Just now, NathanKell said:

@linuxgurugamer The order you get when you iterate over the fields in the type.

OK, thanks.

[linuxgurugamer]

@NathanKell

No one ever explained to me about the order which items appear.  Thanks to your explanation, I've been to convert EEX to not using names to access the hidden fields,and it is now working on Linux.

I'm waiting for some people to test it before releasing.

I understand your position, but find that referring to things via offsets like that to be somewhat, incomprehensible, to someone who doesn't know what's going on.  I much prefer names, which provide documentation (I've taken care of that by using constants with good names).  I'd still like these fields to be available via the "EditorLogic.fetch" (and one for Part), but this is working for now.  I suspect that each new version of KSP will require the offsets to be redone.

Thanks for your patience and explanation

 

LGG

[sarbian]

1 hour ago, linuxgurugamer said:

I much prefer names

yeah, "\u0005" is such a better identifier ! 

[WinkAllKerb'']

if you want a name try "Kim Peek" he used to be 1024bit for part not all

Edited April 25, 2016 by WinkAllKerb''

[linuxgurugamer]

20 minutes ago, sarbian said:

yeah, "\u0005" is such a better identifier ! 

So what I'm doing is first dumping all the members of the class, then creating constants at the top of the files, and then using those constants. so at least it will be easier to understand what is going on.  The constants names reflect what they are pointing at.

Still not happy, but it works (mostly).