Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Black Wolf on June 20, 2010, 04:01:43 am
-
Quick request - any way to slip in a sexp that could convert a numerical value into a string variable? In my specific case I have a temperature guage on the HUD, using HUD_guages.tbl. I currently have 45 sexps converting a numerical variable into any one of 45 strings containing the number in the numerical variable, i.e. 45 sexps ging 'when the variable is >4 <8, modify variable, string variable, "14"'; 'when the variable is >8 <12, modify variable, string variable, "16"'; 'when the variable is >12 <16, modify variable, string variable, "18"'; etc. etc. (Ignore the variation between the >/< values and the string, that's just for balancing since, annoyingly, you can't use non whole numbers in FRED).
Anyway, I could do all of that in one sexp if I could convert a number to a numerical string dynamically. Is it possible?
-
I've also been hoping for this for a long time.
-
Wouldn't that just be a wrap for C's atoi and itoa functions? I haven't used them in a while but it sounds very feasible.
-
It isn't, because the sexp system is only capable of returning integers. :p
What you'd have to do is create a sexp which would write a number to a string variable.
-
IP Andrews asked for this ages ago. It's not that hard to do it the way Goober suggests to be honest. I seem to remember having some objections to it when I was asked a while back but I can't remember what they were.
Wouldn't that just be a wrap for C's atoi and itoa functions? I haven't used them in a while but it sounds very feasible.
atoi has already been wrapped to a SEXP actually. It's just that the other way round was harder.
-
Yea I've asked for this several times as well. Enough that Kara can recite the IPA asked for this by memory from looking up who originally asked for it. :D
-
How come sexps can only return integers?
And on that same topic, how insanely hard would it be to change that?
-
How come sexps can only return integers?
And on that same topic, how insanely hard would it be to change that?
1) It was designed that way.
2) Very hard. The entire sexp system would have to be rewritten.
-
Sexps can also return bool. So are we looking at a total rewrite or just an add on for other types? Yea I can still see it being a major pain but not as bad as a total rewrite.
-
They can return bool because bool is treated as subset of the integers, specifically 0 and 1. You can't similarly treat strings or floating point numbers as a subset of the integers.
So yes, for other types we would be looking at a total rewrite.
-
From my limited experience with the sexp system. There would be three ways of implementing it.
1) Extend the return types so that they include a memory pointer type. This wouldn't actually work very well because of the differences between the size of a pointer and an integer on a 64-bit system (though there are several ways around that problem). You also end up with problems related to the fact that the sexp system relies heavily on pointer manipulation.
This would be fairly easy to hack in, but the issue then becomes how do you manage the memory so that: you don't leak memory, or you don't end up with pointers to the same memory location being used for different things just because they came out of the same sexp.
2) Write a sexp to lua compiler that is run at mission load and then use compiled lua in place of the entire sexp system. This would entire circumvent the limitations of the sexp system and allow for arbitrary return types.
This is probably the most long term useful system, and would allow the FREDers to write either lua or sexp to do everything. That being said, this is also an enormous undertaking and would take a absolutely massive amount of coder time to implement, and then bug fix, because you would essentially have to re-implement the entire sexp api in lua plus implement a bug free translator.
3) Rewrite the sexp system to return objects which manage the pointer to the actual useful information (something like autoptr or std::string. This is also affected heavily be the heavy use of pointer math by the sexp system.
This is probably the most practical implementation, and could potentially be useful long term. Also, it potentially could be implemented without rewriting too much of the existing sexp code. That being said, it would also be a lot of work with fixing assumptions that may have been made and fixing the error reporting system to be able to reflect the new language.
Thus, the only useful solution would amount to a complete rewrite. The others could be potentially workable but they would have the potential to cause a large number of bugs.
-
Number 2 would be my long-term preference as well, but using LISP instead of Lua. The entire sexp language is basically LISP anyway. (That's why they're called "s-exps" in the first place.) It would take considerably less work than a sexp-to-lua compiler, because not only do you not have to translate the language, you wouldn't even have to re-implement any of the APIs.
-
Actually both strings and floats _can_ be represented using just integers, but it would probably be some very ugly code.
-
Well, when you get right down to it, everything on the computer is an integer. You could even represent ASCII strings as base-128 integers in the sexp code if you wanted -- but they would be limited to four characters in length. :p
-
:bump:
Basic request still stands - if Kara hasn't remembered his objections, is there any chance of getting this? All it really needs to do is read a number, and then generate a string of that number... I kinda assume that that shouldn't be very difficult, but I'lla dmit to ignorance. :)
-
Umm. For this specific problem, recent antipodes builds have the hud-set-message sexp, which will set a hud gauge text to a given message. In this message, you can use variables like normally, and the sexp will automatically replace variable references with the proper contents.
-
:bump:
Basic request still stands - if Kara hasn't remembered his objections, is there any chance of getting this? All it really needs to do is read a number, and then generate a string of that number... I kinda assume that that shouldn't be very difficult, but I'lla dmit to ignorance. :)
The basic objection hasn't changed. The sexp system can not do this in any reliable way because the sexp system works on 32-bit values.
-
Well now wait a minute. The sexp system can't return string values, but it's certainly possible to copy a number to a string variable, as I described in my above post (http://www.hard-light.net/forums/index.php?topic=70004.msg1383466#msg1383466). Bump this again in a few days and I'll see if I can get to it, if someone hasn't done it first.
-
i for one wouldn't mind seeing lua scripts embedded in mission files to handle things that sexps currently deal with, or to augment the sexp system by providing object level access. using script for mission logic is already possible, but the real problem is that you would have to ship a heavily scripted mission off as if it were its own mod, because of the mass of tables and lua files that would accompany it. essentially it would be like having a modular scripting table tacked to the mission file.
-
Well now wait a minute. The sexp system can't return string values, but it's certainly possible to copy a number to a string variable, as I described in my above post (http://www.hard-light.net/forums/index.php?topic=70004.msg1383466#msg1383466). Bump this again in a few days and I'll see if I can get to it, if someone hasn't done it first.
:bump:
Not a few days, I'll grant, but... any chance?
[EDIT]I'm a doofus. Found int-to-string - cheers whoever did that :)
-
:p
-
couldn't you just call a script-eval with tostring(x)?
im really not even sure how to get a sexp to return a value or if you can stick that value into a variable, but this line of script would read a num variable and store it to a string variable:
mn.SEXPVariables[stringvarname] = tostring(mn.SEXPVariables[numvarname])
im not sure that would fit in the limited space of a script-eval
-
Number 2 would be my long-term preference as well, but using LISP instead of Lua. The entire sexp language is basically LISP anyway. (That's why they're called "s-exps" in the first place.) It would take considerably less work than a sexp-to-lua compiler, because not only do you not have to translate the language, you wouldn't even have to re-implement any of the APIs.
But our current scripting is via LUA, right? So wouldn't it make it more accessible to scripting if there was a working SEXP-to-LUA vs. a re-write to LISP, or am I missing something?
-
There already is a working SEXP-to-LUA interface; it's called eval-sexp. You can bridge between one system and the other.
What I'm talking about is a re-implementation of the current system. The entire sexp language is LISP, with some FS-specific extensions. If we changed the code to use a real actual factual LISP interpreter instead of our ad hoc, informally-specified, bug-ridden, slow implementation (http://en.wikipedia.org/wiki/Greenspun%27s_Tenth_Rule), the sexp system would suddenly become an order of magnitude more powerful, while retaining exactly the same syntax and complete reverse-compatible functionality.
-
That sounds really interesting.