Author Topic: SCI Companion V3 - alpha build notes/bugs/feature requests  (Read 68170 times)

0 Members and 1 Guest are viewing this topic.

Offline Collector

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #885 on: October 16, 2018, 09:28:40 PM »
As mentioned on Twitter and related to the above post, my SCI Companion now has special handling for the File class. Assuming script 996 is always File.sc and Class_996_0 is File, it'll notice if it's that or gamefile_sh and call it File after all.

Astro Chicken names script 993 as File.sc with you build. the only error is "Error: (Main.sc) Unknown class 'gamefile_sh' .  Line: 759, col: 9"
KQII Remake Pic

Offline Kawa

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #886 on: October 17, 2018, 03:36:03 AM »
Right, forget that feature then. Between that and the endless redeco loop I encountered it might be better to just not enable those hacks.

Offline Kawa

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #887 on: October 21, 2018, 04:25:13 PM »
So apparently there's a bug where expressions like (+= [array someThing] 5) don't compile right. This has been fixed in the latest Experimental-branch commit, and I just integrated it in my own builds.

New MILD release: http://helmet.kafuka.org/sci/SCICompanion.exe

Included hacks: some vocab resource preview stuff, Display argument massaging.
Not included: the globals and script names thing... and the latest compiler feature, the &exists keyword. If you want the ability to say (if (&exists someParm) ...) instead of (if (>= argc 2), let me know.

Offline MusicallyInspired

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #888 on: October 27, 2018, 03:59:14 PM »
I wish you could get past your differences with GIT. It would make tracking your additions it easier.

I don't know if this influences anyone's decisions to use it one way or the other, but I've just learned today that Github was purchased by Microsoft for $7.5 billion. The co-founder has already stepped down.
Brass Lantern Prop Competition

Offline lskovlun

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #889 on: October 27, 2018, 04:30:51 PM »
I don't know if this influences anyone's decisions to use it one way or the other, but I've just learned today that Github was purchased by Microsoft for $7.5 billion. The co-founder has already stepped down.
GitHub is not Git. Just sayin'.

Offline MusicallyInspired

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #890 on: October 27, 2018, 08:10:37 PM »
Oh. Please ignore my ignorance.
Brass Lantern Prop Competition

Offline Collector

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #891 on: October 27, 2018, 08:54:59 PM »
there are other GIT services. All of my stuff is on Bitbucket.
KQII Remake Pic

Offline Kawa

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #892 on: October 28, 2018, 05:13:02 PM »
Well, gentlepeople, I hope you're happy. Despite previous experiences with keys and shit, I found a way to git Git to work.

Which means yes, my horrible, horrible changes are now exposed to all the world.

Offline Collector

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #893 on: October 28, 2018, 08:41:28 PM »
Thanks for that.
KQII Remake Pic

Offline Kawa

Re: SCI Companion V3 - alpha build notes/bugs/feature requests
« Reply #894 on: November 06, 2018, 08:51:56 AM »
If you were to look at a random polygon-using Sierra game's decompilation, you'd see something like this.
Code: [Select]
(method (init)
(gRoom addObstacle:
((Polygon new:)
type: 2
init: 150 108 114 115 ...... 187 80 191 102
yourself:)
)
)
(super init:)
...
)
That's quite unlike what a Companion game would have.
Code: [Select]
; from (include 200.shp)
(local
[P_Default200 29] = [1 PBarredAccess 13 150 108 114 115 ...... 187 80 191 102]
)

(method (init)
(AddPolygonsToRoom @P_Default200)
(super init:)
...
)
Especially when you consider that the resulting bytecode is nothing alike, and the raw polygon data remains in the heap throughout the room's lifetime as locals. And you get a limit on how many points you can have under a single name.

In that light, I've been sitting on an idea that I implemented this morning, inspired by Phil's foreach keyword and my own "make it iterate through a Collection" hack. I made a getpoly keyword.

Giving each individual polygon a distinct name because reasons, you can now remove the include line, add a (use Polygon), and do this:
Code: [Select]
(method (init)
(gRoom addObstacle: (getpoly {Beach}) (getPoly {Path}) ...)
(super init:)
...
)
When compiled, each getpoly will expand into a ((Polygon new:) type: X init: ... yourself:) statement matching the .shp file. Convert all rooms and you can throw away those helper functions entirely.

This feature is available now on Github.

Edit: (getpoly {}) is now acceptable and will grab the "Default" poly. The internal thing that the polygon editor uses doesn't expose that with a name, hence the empty text box in the editor. This also allows the New Room dialog to generate something with minimal fuss.
« Last Edit: November 06, 2018, 01:08:55 PM by Kawa »


SMF 2.0.14 | SMF © 2017, Simple Machines
Simple Audio Video Embedder

Page created in 0.21 seconds with 23 queries.