Would any behaved experts know if it was possible to achieve some sort of credit chip counter? I thought you could do something like SET PARM_1 n+1 if you wanted 1 to be added to your credit count This would be really good if this could be achieved, for there could then be quite a few KOTOR-esque mods, I imagine
Taken from Map-Craft:
"BobaFett"I, being a map editor (changing the entity lump in bsps) have a lot of experience with abusing entities and using icarus scripting... While T-RCX and I have been working on Hevil Spaceport (a big modification of t3_hevil), we found a serious bug in ICARUS. I'll tell you the bug in a few, but first...
I've seen that mappers, especially Nab and Szico, have been using scripts in their latest maps. I've done a little check on Nab's Taspir Power Complex v3 and Szico's Atlantica. (checkin out the ent usage and scripting)..
Both of them make extensive use of scripting (as we probably know already), quite efficiently i might add. There's a little somethin I noticed in Atlantica though.. The money system used in it, works with a parm. (no biggie, but read on) When you get money, or pay something, the parm is incremented/decremented. Now i'm sure to most of you dont see the issue in it... but the thing is that parm incrementation is bugged. Incrementing a parm, will wipe all subsequent parms and corrupt the heap if parm2 and up are incremented. This is due to a minor coding error, which in result causes a quite serious bug... The only mod i'm aware of that fixed it, is Lugormod, so most mods still have the issue.
So to keep your map from causing issues on servers, or magically having its parms disappear, dont increment/decrement parms!
If you MUST increment parms (which is a likely situation if you want to make a money system or something like that), use SET_COUNT as a temp var, as SET_COUNT is the only other field supporting incrementation and the only, which does it right. Its also not used by players, so its safe to use it. On other ents, you might need a backup of it or avoid incrementation altogether.
So instead of using Set ( "SET_PARM3", "+50" ) (which would corrupt the heap and wipe parms 4 to 16), use the following 3 lines, for safety:
Set ("SET_COUNT", $get(FLOAT, "SET_PARM3") ) Set ("SET_COUNT", "+50" ) Set ("SET_PARM3", $get(FLOAT, "SET_COUNT") )
Just thought i'd warn you about this bug, so that your future maps with scripts will take this into account.
This is indeed possible, and in fact a map that myself and BobaFett have been working on utilizes a fully operational credit counter system giving each player his own unique "bank account" as it were...
However the problem is that to fully create this system is much more complicated than it sounds, and the most ideal implementation takes an extremely advanced understanding of Icarus.
For example, you had the right idea initially with using player parms to keep track of a "money" value, but right away we have two problems with this: 1) incrementing a parm is bugged (ie, using set SET_PARM1 "+1") and attempting to do so will wipe out all other parms and corrupt the heap (which is a bad thing) [EDIT: I see this has been touched upon by the above post], and 2) player parms are retained even when a player disconnects, so any subsequent player that joins the game in the same slot will inherit all previous parms.
Of course, a bit of thinking can indeed yield solutions to these problems, but these workarounds only increase the complexity of the script and the level of thinking at which the scripter must operate. Then even if you solve these problems, you still have things to consider like "how will the player keep track of how many credits he has?" which while not completely necessary to creating the system would be something that you would naturally expect to have in a money system, but to have such a straightforward ability requires highly complex scripting (you can't simply print the value of a parm in any normally readable way, so you basically have to create math operators using only incrementation).
So in short it is possible, but to actually do it completely is not a simple task.
Say, where can I find this map you guys are working on?
~*Seto*~;4934264So in short it is possible, but to actually do it completely is not a simple task.
Since you are working on an MP project, can't you just fix the code so that you could directly print variable values?
Indeed on the coding end it would be simple, but the particular thing I'm referring to here is a map mod only and not related to anything else you might've seen around here, like the JKG mod. Actually, we started it before JKG (and indeed you might even say the theme of it was a pseudo-JKG RP map), but because of JKG it has now been put on hold for awhile since JKG is a bit more exciting and important to work on.
"Crazy Assassin"Say, where can I find this map you guys are working on?
If you find Boba sometime and ask him about it, I'm sure he'd be willing to put up his server and show off our incomplete work.
Displaying the credits is easy, with a little brushwork and some textures. Make a few textures for the numbers 0-9, and then use either shader remaps or a 10-sided func_static with one texture on each side. Put these numbers into a terminal. Then you can either remap the numbers or rotate the func_static to the appropriate angle to display the numbers. So whenever a player uses the terminal, the number of credits appears (I prefer the rotating func_static method, because there's less bugs and more animation involved).
This is quite complex, though, and requires the ability to create your own brushes, which entity modding cannot offer. But still, it'll be kewl to do so.
Even with that method, you still have to be able to dissect the value stored in the parm in such a way as to be able to display each digit correctly, which requires some complex math scripting. But yes doing the brushwork would be much neater looking than the way we had to use, which was printing out each digit of the final number individually.
Yeah. I have basically something similar to Nab's description in use in Bespin Range (my other WIP), for displaying the round number and the final score. The scripts needed to dissect the variable values and control the individual number entities are indeed long and more complex than I'd personally bother to explain to any scripting newbie. Still, I needed to do it in any case, due to the setting and atmosphere of the level. Printing variable values, even if it had been possible, wouldn't have sufficed. But that map is a veritable jungle of scripting in any case, so it was nothing much in the bigger picture...