Using ByReference in structs possible?

[FaceMn]

Works out okay for me. Here is the quick example I made:


fn myFunction &myVar = (
myVar = true
)

struct test (
var = false,

fn init = (
myFunction &var
)
)

t = test()
print t.var
t.init()
print t.var

[f97ao]

Ok, thanks. I will look into my script in more detail when I get home. Hopefully I'm just doing something stupid.

/Andreas

[f97ao]

I still can't get it to work :(

This is the function that I'm calling with a reference variable. (the function is part of a bigger struct for handling load/save

fn Update Action variableName &Variable Default =
(
--IniClass.Update #Save "Lock" &Lock true
if Action==#Load then
(
tReturn=(Load variableName Default)
break()
return tReturn
)
else --#Save
(
var=Variable
break()
tReturn=(Save variableName var)

return tReturn
)
),



This is how I call it. I call the function from inside a struct. Lock is a local variable.

TestIniClass.update iniAction "Lock" &Lock false

If I instead write like this

newLock=Lock
TestIniClass.update iniAction "Lock" &NewLock false

then it works, so the problem seem to be because of the Lock variable.

This is the error message:

-- Error occurred in update(); filename: C:\3dsmax8\Scripts\Polyspeed CODE\windowsclass23.ms; position: 4819
-- Frame:
-- Variable: <<error printing value>>
-- action: #save
-- default: false
-- variableName: "Lock"
-- var: <<error printing value>>
-- tReturn: undefined
-- called in INIUpdate(); filename: C:\3dsmax8\Scripts\Polyspeed CODE\windowsclass23.ms; position: 71545
-- Frame:
-- newCategory: #no
-- iniAction: #save
** system exception **

If I use Global variables inside the struct, then the load/save works. Very strange. I think the problem comes from the fact that Lock is a local variable in the struct, but not in this very function. (it's declared when I create the struct).

/Andreas

[FaceMn]

Just trying to get a grasp of the code you are trying to execute here. Would you say this example is relevant?


struct test (
var = false,

fn update &myVar = (
myVar = true
),

fn init = (
update &var
)
)

t = test()
t.var
t.init()
t.var

If all of the functions for your example are in the same struct, I don't see the need to call them by using the struct name first. Instead of TestIniClass.update <args> you could instead (if the function is inside the struct) just say update <args>.

[f97ao]

Just trying to get a grasp of the code you are trying to execute here. Would you say this example is relevant?


struct test (
var = false,

fn update &myVar = (
myVar = true
),

fn init = (
update &var
)
)

t = test()
t.var
t.init()
t.var

If all of the functions for your example are in the same struct, I don't see the need to call them by using the struct name first. Instead of TestIniClass.update <args> you could instead (if the function is inside the struct) just say update <args>.

Hiya.
No this is not the same

I have 2 different structs. One is for handling Ini objects, one is for handling interfaces.

The Interface Struct HAS the Ini Struct as an object. Functions in the Interface Struct calls the Ini Struct. When I call the ini class I send in several variables byreference that I hope to update.

For this example I skipped the ByReference, since it just didn't work. But it would be nice to have it working in the future.

Right now I do something like this instead:
IniAction=#load --can also be #save
Variable=IniClass iniAction "Variable" Variable

This way I can both load and save the Variable with the exact same command.

Hey, can't you guys do Descent 4? Descent was one of the best darn games ever made. I never had so much fun in multiplayer, EVER. :)

/Andreas

[FaceMn]

Ahh, I didn't realize you were doing this with two seperate structs. I must have missed that.

The Descent 4 discussion pops up from time to time here, but sadly, I don't think another version will ever be made. Besides, there doesn't seem to be a market for that type of game anymore.

[f97ao]

The Descent 4 discussion pops up from time to time here, but sadly, I don't think another version will ever be made. Besides, there doesn't seem to be a market for that type of game anymore.

Yes, hmm it's a shame. One clear problem was that it wasn't very accessible. It was after all freaking hard to control the space ship, but when you DID learn to fly backwards in tunnels avoiding smart bombs, oh boy then it rocked. Perhaps if it was more packaged as a multi player game, it could work. It was never that much fun in single player actually.

/Andreas

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.