I just had an idea, that modders who are good with ASM can write a plugin which will enable to use multiple flingy entries (not really, but similar effect).
You need to be a dummy to not notice that images.dat has plenty of entries, and many of them unused. Sprite has less unused slots, and half as much entries. But what really limits the modder, that flingy has only 208 (!) slots. And it kinda sux. Because in order to add animation to a unit, we always start from the flingy, then descend to sprite and only afterwards to image data. And what exactly is flingy? Its physics of the unit, its speed, moreover these settings can be overrided, if you set speed to iscript.bin which completely nullifies all the data in the entry. Note that iscript.bin, has LIMITLESS!! amount of entries. (at first I thought its limited to 411, but its actually not at all). Wait let me think... if we just change IsID of an image entry, we can make a totally new graphic, out of the same grp, (for stupid: one IsID will use framesets 0x00, 0x11. 0x22, etc.., the second IsID uses the same grp's framesets of 0x33, etc... thus we insert multiple unit's graphics into one grp and consequently image file). This way you can even create one Biiiiiiiig grp that will content all the graphics in the game.
If you think that this is too time consuming, or for other reason think this is not good/will not work for some reason, then what if we just changed flingy entry or sprite pointer in game? It would allow a much broader range of unit graphics, and this means new units with their own peculiar graphics.
Notice that many of the game graphics, such as explosions, doodads, don't even have their own flingy, e.g. work fine without it. For that reason I suggest that in order to do make new graphics we would need assembler code, that locates the entry pointer inside flingy. dat and changes its value to point to some other sprite or just iscript ID, and here we got a new unit!

I don't know how the code of starcraft works, so perhaps this method would create problems, such as changing graphics for all of the units at the same time, but hey, at least it would that there could be algorhytm that upgrades units and their graphics. I think that it would be very possible to create a plugin that would mess around with flingy or image entries, thus adding new graphics to units. 8->

Too tired to think through your mass of text, emoticons, and BB code.

Would you mind completely redoing your post? All you're doing is ranting.
Please reorganize your post so as to be clear and concise.

What he is saying is using iscript to be able to build graphics out of a few frames.
I think... D:

You don't know what ASM is, do you?

ASM is Assembler, no?

Too lazy for advanced modder, huh?
Well here is the deal:
Make assembler code that modifies image or flingy entries during the game (modifying the value of the pointer to sprite, or IsID accordingly).
This way it would be possible to make more graphics out of the same flingy/image. Meaning more units/stuff

What I meant is, you don't need to make any ASM plugin, because you can just do this with iscript.

Maybe what DS means to say is to use ASM to change image.dat iscript references to different ones in-game.

E.G. image ID 1337 normally points to iscript ID 300. Using an ASM plug-in, we change image 1337 to iscript 9000+n during run-time.

I don't really see the point of that, except that it would help with making upgradable units.
E.g. the upgrade "MASSIVE MARINES" triggers the ASM plug-in when it finishes, causing all units with image 1337 to switch from girly ID 300 to manly ID 9000+n, resulting in many more useweapon opcodes.

Yeah, I still don't get the point of this. Neither do I think that DS knows what he is talking about (same problem on my part - I know next to nothing about ASM).

That would cause ALL players to get the upgrade. And probably desync as well.

You can still do that upgradable units thing, btw. Find some iscript block you can call with a trigger, and in that code block, spawn an attacking overlay. (eg. the Archon Being overlay, which is what actually does the attacking when an archon attacks) Then, when the player researches the upgrade (detected through EUDs or something), make all units of the type that benifits from the upgrade call that code block.

Ok none of that would work at all.. Firstly you talk about a way around the limited flingy.dat entries, and your way around it is to combine unit graphics into one GRP? That doesn't make a difference at all, you still need two different images.dat entries to point to te different iscript entries (and the images would need two different sprites pointing to them, and need two different flingy's to point to them), which is the same as what you would do if you had both units with their own GRP's. Also as TZ said, changing anything in that DAT files in game would modify it for all players (but it wouldn't desync unless you did it in a dumb way).

Actually, when I was making this post, I somehow didn't realize that flingy.dat affects all the units, so by changing flingy reference to different sprite you change the graphics for ALL of the units for all players that are using that flingy. So it does mean that the only way to insert multiple units in one graphic, is to make iscript entry that has a higher level of programming, and as well include a grp, that stores data from multiple units (we want to use for that flingy). I was just giving an idea for making extra slots, that's all, I didn't come to a completed solution.

So what I am suggesting is this:
Using assembler modify the iscript entry. Example:



And here we have an example of pseudo iscript code that would allow tank graphic have different turrets (subunits) depending on the unit ID.
If something like that was made available via iscript.bin or assembler...
Well you get the idea...

That would be possible if you know how to modify iscript.bin opcodes. Which, according to DoA, is like pouring alcohal on your dick and lighting it on fire. In other words, it's theoretically possible, but nearly impossible.

I'm quite sure that's not possible, since when one compiles a text file to the iscript.bin file, comments are stripped, thus making comments an unfeasible option for use.

BTW: You don't seem to know too much...

-

Okay, now it's my turn.
Would it be possible to completely dereference iscript opcodes to do something completely different? E.g. add lines of ASM that the opcode is simply edited to go to?

I take it that you are ready to try to sacrifice your dick..

Please try that, that would be the most advanced breakthrough in starcraft modding. Imagine what would be possible to do in iscript.bin if you just had If operator, and access to game variables.

He was just using them as comments, probably.

Yes, but it would be like pouring alchohal on your dick and lighting it on fire.

Yes it would be.

... FUCK YAH. I'm going to fucking do this. DoA, I'm going to need you.

This would actually be pretty useless seeing your example.

The tank iscript is only used by two units, the marine is only used by two as well, and so on.

Unless you give the same iscript to several units it will be worthless since you wouldn't have many "ID"s to play with.
Giving the units the same iscript (or to a lot of them) would be so terrible, you would have to make a complete disorder with a single GRP that controls all the graphics unless you pretend to randomly call several overlays. GRPs can't handle much information (by Mesk's experience), He had over 300 frames or so and it was as stable as a flan, even when you don't have a frame limit it certainly causes flaws.

This would only be useful if someone actually (supposed they made it) makes it so that instead of unit IDs you can call another variables stored in memory and not just IDs, then again, I do not even have a remote idea on how someone could manage to do this without all the tons of problems it can create, desync, random crashes, overflows, calls to undefined variables, ...etc.

Worthless? Well for you maybe... o.O
It seems that you do not understand my idea at all. The goal was to make iscript flexible, so to make one IsID that has many subfunctions or graphics, each designed for a certain unit. Then you add all of these units this very IsID, and the scripts acts upon it (unit ID), resulting in one flingy holding multiple graphics. (grp would also require to have framesets from all of the above units). If you think adding too many frames will result in instability, or too many subentries in IsID "would be so terrible", then who said that you need to stack all the frigging units in one friggin grp, and make a single, friggin big IsID entry?
Its supposed to be small groups of units which have pretty much the same characteristics, for example tanks with different turrets, [or like goliath, plus supa goliath, plus supa friggin goliath with balls (subunit) ]. It means their types are pretty much the same, except they got different stats, or they could belong to different races, (if its a mod with 2 terran races for example).

You say its impossible to make this without crashes? Have you even tried? No? So sit back, and watch TassadatZeratul make a plugin for that

Actually I could make Dominus Sacerdus's suggestion in a plugin quite easily (i've been working on a a little something concerning SC's iscript handler, so i know a lot about it now), though it would just be a custom "condjump" opcode, not the weird IF example.

YAY!!
If you can make blablacondjump opcode, then please make LOTS of it. I mean on every single variable you can, like Unit_ID, weapon_ID, isusingtechnology, ishavingupgrade, has fuillfilleddatarequirementinthatfiregrafttaband other opcodes like that.
Also if you could add action opcodes like modifytargethp/shield/mana, that would make starcraft one level more customizable

Thank you! =)


P.S.
What's so weird about IF opcode? Its commonly used in C++ lol

I might do it, but then again doing lots of opcodes would be a lot more work then just one opcode. You also probably didn't even think about having a program to compile these custom opcodes into an iscript.bin. I can also make a custom PyICE for the purpose, but thats more stuff to do. Would take lots of time. If there are enough people that would use it, and a bunch of people figured out a list of opcodes which would be useful, then its possible i'll do it.